 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
chASM
Newbie cheater
![]() Reputation: 0
Joined: 23 Jun 2011
Posts: 17
|
 Posted: Thu Jun 23, 2011 7:50 pm Post subject: [BUG?] _ExportedFunctions Structure & some other stuff |
 |
|
Hey,
While coding a plugin for CE 6.1, my unit testing returned something peculiar regarding the _ExportedFunctions structure within the 'SDK'.
Note: This is the 32-bit version, which I have had to use since the 64bit version of CE automagetically started crashing every time it needs to display an 'open file' or 'save file' dialog (you know, the system one). I do not know if the same issue exists when running the 64bit CE, at least, until I manage to get it back to work.
Note 2: The plugin is a combination of C++ (using a custom plugin header file, which works fine) and MASM (more MASM than C++, though).
I've attached an image of the first 56 entries, which outlines (literally) the issue, in red. anything coming after the first 54 seem to be okay, albeit that I have not tested most of those as I do not need most of them.
The rows in orange are warnings that something is inconsistent with the previous test run (which, considering what those pointers point at, probably means nothing).
Anyways, have a look at the attached image.
Number two's turn:
It seems that CE doesn't execute DllMain properly (if at all?), my 'DLL_PROCESS_ATTACH' and 'DLL_PROCESS_DETACH' never execute, preventing me from doing clean up in case 'CEPlugin_DisablePlugin()' doesn't execute (see next point). Same goes for anything that would need to be in 'DLL_PROCESS_ATTACH', which for complex plugins may be needed (although one usually tries to keep both empty).
Another one:
When CE closes (be it due to the user quitting or a crash), 'CEPlugin_DisablePlugin()' is NOT called by CE. Combined with the 'DLL_PROCESS_DETACH' not executing, this leaves NO ability to clean up for the plugin. Mine uses a fair amount of allocations, some of which will severely leak if the DLL is just thrown out the window (pun not intended) without proper clean up. Also, any allocations made in OTHER processes cannot be cleaned up, including properly ejecting a DLL!
A good example is my plugin development, since I have to restart (CE doesn't unload it when the plugin is disabled) CE every time I do a test run or a unit test cycle. With heavy testing (e.g., while bug hunting) then every hour or so, I need to log out and back into Windows (7, x64) because the system runs out of memory (and I have 4gb), which is a tad annoying. On the flip side, this a BIG plugin, and mostly not even related to cheating (it is development/debugging related, targeted at games, but just as much applicable to applications), so it's probably not a huge issue for most plugins (although I have been able to find VERY few plugins as is).
Aaand:
It would ease plugin development if CE would UNLOAD the plugin when it is disabled in the settings, and RELOAD it when re-enabling it. Right now CE needs to be restarted for every test. Combine this with the 'inability to clean up' issue above and one has a fairly severe issue, especially when dealing with code/dll injection into other processes from the plugin.
In fact, even disabled plugins are loaded by default when CE starts, bit of a waste of memory there and completely useless at that.
Closely followed by:
The auto-assembler editor under 64bit CE. Why can I not copy and paste from notepad (or something like that) into the editor? Some of my unit tests require the auto-assembler to 'talk' to my unit testing application, and it is nasty that I cannot simply copy and paste. However, this one MAY be on my side as I have had some drag & drop issues in Windows 7 x64 itself (where it works between x64 and x32 applications but NEVER works between x64 and x64, extremely odd one that), but I have not had any copy & paste issues like that before. Also, I CAN copy and paste between two AA editors without problem!
And last (but certainly not least):
I am aware that CE has always been a bit 'rough' around the edges but here's a small list of annoyances, do with it what you will, they are mere annoyances after all, apart from the last one, which is down-right irritating:
Dragging & dropping headers in the address list is a nightmare..
Copy & paste actual addresses is severely broken, paste is the mirror of the original (I am sure you are aware of this one), observed under x64 only, not tested under x32 as I haven't used the address list in that manner yet since CE64 began acting up.
Copy & paste headers please.. even if it contains addresses.. (hell, especially if the header contains addresses).
Trying to delete a large selection of addresses from the 'found addresses' box still crashes CE, hard.
Does the installer really have to wipe ALL of the settings of the previous version on install? Highly annoying, but with the huge release intervals CE gets, not a big issue.
The most annoying one by far... When CE crashes, then, upon next run, it really SHOULD clean up the 'temp' directory where it stores search results. Several times now I have had to remove 10+ gigabytes of 'search remains' from 'temp' because they were still there after a crash. I assume this 'temp' directory normally defaults to the actual 'Temp' directory that Windows provides, and as thus CE can really quickly fill up the Windows partition/drive, which poses countless issues for Windows (down to a BSOD, even under Win7). I always point it into a 'Temp' directory within the directory where CE is installed, enough crap goes into Windows' 'Temp' as is, and no, I don't install CE under 'Program Files' either, since it is outside of context there, it's in my 'Tools' directory structure, on a completely separate drive, where stuff like CE belongs. Most people probably just click the hell away in the installer, and most likely also never bother touching the 'settings' within CE itself, which can lead into issues astonishingly fast (large game, unknown initial value.. big ass files).
I've got more, of course, (for example, and no offense, but the plugin 'SDK', can barely be called that, and really needs to be redesigned into a proper API) but nothing 'important', as I stated before, CE has always been a little rough around the edges, gives it character. Feature-wise, it's awesome, and that totally makes up for the 'design-along-the-way methodology' (which is assumed based on the source code, it just has that 'look' to it, I am no Delphi expert though, Turbo Pascal under DOS was the last Pascal-like for me, the CE sources are perfectly readable though, albeit filled with a lot of verbose code) that created the rough edges in the first place.
Thanks for reading this rather lengthy post.
Keep the awesome work up Dark Byte, I'll send a donation your way once I am done with the set of plugins I am creating.
Regards,
chASM
| Description: |
| First 56 entries of _ExportedFunctions, entries outlined in red are problems (at least point them to a 'catch' pointer, otherwise CE will simply crash), orange is a warning something changed between runs. |
|
| Filesize: |
116.13 KB |
| Viewed: |
4022 Time(s) |
|
|
|
| Back to top |
|
 |
Dark Byte
Site Admin
 Reputation: 470
Joined: 09 May 2003
Posts: 25796
Location: The netherlands
|
| Posted: Fri Jun 24, 2011 12:15 am Post subject: |
|
|
Ok, I'll add some specific unloading for next version
As for loading disabled plugins that is required to fetch the plugin name (so don't do anything tricky in the DllMain and wait for CEPlugin_InitializePlugin )
The pointer being null is 'normal' as it is for backward compatibility of older plugins that do not make use of the obsolete functions. The debugging routines have been completly rewritten between 5.6 and 6.0 and the kernelmode debug functions are now implemented in the abstract debuggerinterface class (not yet exported except in lua)
I could put up a message that it's not supported anymore, but as far as I know, there are no plugins that use that (at least, no one ever told me they used it, or showed such a plugin)
The addresses being different on each restart is also normal. The OpenedProcessID and OpenedProcessHandle elements are pointers to those variables.
That allows you to override openprocess and give it your own handle and processid
The addresslist copy/paste: Not really sure what you are talking about. You do know that you can enable the simple copy/paste option in settings ?
Also, it does clean up the temp files, but not as fast as you think. Each time you close cheat engine normally it will clean up the tempfiles of the current session, but also tempfiles that are older than 2 days. (you can run multiple versions of Cheat Engine at the same time, for whatever reason you might have, and one deleting the tempfiles being used by another ce can be annoying)
Copy/paste between AA and notepad: I have heard reports of people having trouble with that, but I haven't been able to reproduce this.
Do you have a special character support tool running ?
Or who knows, perhaps an anti virus has deemed cheat engine as unsafe and is blocking it access to the clipboard when the content is generated by another process?
The auto assembler screen (synedit) is an external component, but perhaps there's a fixed version out next ce release
As for the plugin not being a real 'SDK' , perhaps, but the gecko plugin API basically does the same. Just a pointer to a structure containing the functions. But yeah, it could use some more documentation (Which is something I hate doing)
| Quote: |
because the system runs out of memory
|
Just out of curiosity, what are you doing? allocating nonpaged kernelmode memory?
Windows usually frees all usermode memory on process termination (and if you allocated in another process, closing that process has the same effect)
and even if you have 12 processes with 1GB allocated, as long as that memory is not accessed it will get paged out to disk when low on available ram
Also, please report every minor bug, even if you think I already know them (There are some features I myself hardly use, like copy/paste)
And it helps if you also (or just) report them in the bugtracker.
That will be the first place where I look when starting on the planning and design for next version
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
chASM
Newbie cheater
![]() Reputation: 0
Joined: 23 Jun 2011
Posts: 17
|
| Posted: Fri Jun 24, 2011 3:42 am Post subject: |
|
|
| Dark Byte wrote: | | Ok, I'll add some specific unloading for next version |
That would be awesome, much appreciated.
| Quote: | | As for loading disabled plugins that is required to fetch the plugin name (so don't do anything tricky in the DllMain and wait for CEPlugin_InitializePlugin ) |
Simply unload them again after you get the name, a simple FreeLibrary() call isn't going to slow things down a lot. After all, the plugin is disabled, and needs to be re-enabled in the settings for it to load again anyway.
Actually, a bit of extra effort there could result in a far superior plugin handler. Don't even bother loading known yet disabled plugins, simply store each plugins md5 hash, state, and plugin name. Then the only operation is to calculate the hash for each plugin when CE starts, that doesn't require one to OpenLibrary() the dll file, perform a simple compare on the hashes and you have all the puzzle pieces. At the same time, CE can then 'recognize' new plugins as well, OpenLibrary() them once to fetch the info, default its state to disabled, add it to the plugin list and perhaps indicate this to the user somehow. Easy enough to code, bit more time consuming upon first run with more than a few plugins installed but far more efficient in the end. As a bonus, it is more 'modern' in design than a simple 'just load all dlls and see what happens' and is certainly more stable and less resource hungry. Bit more work though.
| Quote: | The pointer being null is 'normal' as it is for backward compatibility of older plugins that do not make use of the obsolete functions. The debugging routines have been completely rewritten between 5.6 and 6.0 and the kernelmode debug functions are now implemented in the abstract debuggerinterface class (not yet exported except in lua).
I could put up a message that it's not supported anymore, but as far as I know, there are no plugins that use that (at least, no one ever told me they used it, or showed such a plugin). |
Simply mark them as 'obsolete' is what I do in those cases, or, if I have the time, they would become 'wrapper' functions for the new class, retaining backward compatibility.
My issue is not so much that these functions are dead (although one should never remove functionality in favor of new, but similar, functionality elsewhere, sometimes it can not be helped though) but with the fact that they point at nothing. If a user codes a plugin, calls one of these functions and CE produces a nice fat 0xC0000005 for them, then confusion might set in with less experienced programmers, usually not a good thing. Instead, I would have the functions point to a function that simply returns 'false', which results something that a person can use, an indicator that something is not right, then they might perhaps just open the help file/go to the forums and find some info on it. A better direction than a hard crash on trying to execute address 0x00000000 (add 8 more for x64), think of the horror in the eyes of the new-ish to programming person when confronted with a minidump.
| Quote: | The addresses being different on each restart is also normal. The OpenedProcessID and OpenedProcessHandle elements are pointers to those variables.
That allows you to override openprocess and give it your own handle and processid |
That's pretty much exactly what I figured, it's memory allocated by CE, so it changes location. I have no problems with this apart from my work perspective, a plugin host system should never allocate memory for a plugin, which in the case of CE doesn't matter all that much since there seem to be very few plugins to begin with. Potentially, my current 'project' could make CE very unstable in this regard but it isn't meant for the masses anyway and I can work around any issues easily.
| Quote: | | The addresslist copy/paste: Not really sure what you are talking about. You do know that you can enable the simple copy/paste option in settings? |
Yes, i am aware of the simple copy/paste option. My project however can't use that, as it dynamically sets up address lists, at a very fast rate while 'trying' to use your address list control as a tree (using headers), at the moment these things are done by an outside application (the plugin communicates with it, eventually, it will be integrated), so it generates in the xml format. Since it is early on in the project, there is no named pipe solution in the plugin yet, so the outside application simply throws it onto the clipboard, the plugin pastes it into the address list, I am aware that the plugin can simply add address list items, but like I said, currently the comms between the outside and the plugin is rudimentary, at best. The plugin as thus doesn't have an xml parser, and if I had to code that in there, I might as well do the whole named pipe business, takes about the same amount of time. Currently, it is meant to proof a concept, not be 'pretty'.
The issue I have is simple though, and I can replicate the behavior by copy/paste within the address list itself. Copy a bunch of items to the clipboard, and paste them, the result will be reversed from the original, so, the bottom item I copied, becomes the first of the pasted items. It seems you iterate bottom up, but add top down to the address list. I guess the clipboard acts like a stack in this case, so the bottom item is on top after a copy, a paste will 'pop' the items off that stack but add them below one another, reversing the original order.
Workaround is easy too, just cut and paste the newly pasted items again, and it reverses to the correct order. A little annoying perhaps, nothing huge. It is not the only clipboard issue though, more below.
| Quote: | | Also, it does clean up the temp files, but not as fast as you think. Each time you close cheat engine normally it will clean up the tempfiles of the current session, but also tempfiles that are older than 2 days. (you can run multiple versions of Cheat Engine at the same time, for whatever reason you might have, and one deleting the tempfiles being used by another ce can be annoying) |
It certainly doesn't do that here! Hell, earlier I found one from four days ago in there, at 3 gb in size. Perhaps it doesn't work well when the temp directory is set to a 'non-default' location (which is the case on my system, the temp directory is inside the CE directory on my D: drive, as specified in the CE settings)?
Also, it is easy to have a second instance of CE 'know' that temp files are in use by the first instance, simply drop an empty file called 'locked' or whatever along-side the temp files, the second instance then knows not to touch those files, or if the time stamp on the 'locked' file is older than a day or two (indicating a crash, as that file should be removed when CE closes normally), it can delete the temp files. Either way works I guess. It's not a huge deal, plenty of disk space, and I keep an eye on it.
| Quote: | Copy/paste between AA and notepad: I have heard reports of people having trouble with that, but I haven't been able to reproduce this.
Do you have a special character support tool running ?
Or who knows, perhaps an anti virus has deemed cheat engine as unsafe and is blocking it access to the clipboard when the content is generated by another process?
The auto assembler screen (synedit) is an external component, but perhaps there's a fixed version out next ce release |
I have this one figured out, it's the other clipboard issue I mentioned above. 'Synedit' seems to have more than one clipboard slot, and it is pasting the wrong one. It works when I flush the clipboard from code and then copy and paste something, the moment I copy and paste something else, 'Synedit' pastes the PREVIOUS copy/cut that was made. This also explains why it works between two AA windows, those know what slot to use. It is a bit odd to paste into notepad and get something different than when I paste into an AA window.
Seems likely that 'Synedit' isn't tracking the clipboard and keeps an internal index/offset to the clipboard, or perhaps it is a custom system built on top of the Windows clipboard. In any case, I would consider it a bug (where it is located, I do not know, 'Synedit' seems likely, but it could be CE as well, I have no experience with this editor myself).
| Quote: | | As for the plugin not being a real 'SDK' , perhaps, but the gecko plugin API basically does the same. Just a pointer to a structure containing the functions. But yeah, it could use some more documentation (Which is something I hate doing) |
You WRITE documentation? Isn't Delphi capable of inline documenting? Then your comments (specifically tagged ones, have a look at the abilities of C# in this regard) become your documentation (including example code, links to other documentation pages, lists, etc).
I hear you on the hate for writing documentation, I am a coder, not a writer. So, I built a system like .NET uses for our somewhat more proprietary environments (PC's are fun, but certainly not computers one should trust the lives of people with). We use either specifically designed hardware or mandated hardware, although Windows is used a LOT during the design and development of such hardware and the software that needs to come with it. In fact, we're moving to do ALL coding of these obscure systems on PCs using cross-assemblers, since it is a lot cheaper.
| Quote: | Just out of curiosity, what are you doing? allocating nonpaged kernelmode memory?
Windows usually frees all usermode memory on process termination (and if you allocated in another process, closing that process has the same effect)
and even if you have 12 processes with 1GB allocated, as long as that memory is not accessed it will get paged out to disk when low on available ram |
I can't be too specific (the industry I work in is the cause of that) but as I mentioned above, we want to move all coding for specifically designed and/or obscure computer systems to the PC as a cost saving measure as well as higher productivity. This means we need a universal way to connect these systems to PCs. Basically, I am prototyping a device driver system that allows that 'universal' bit to work. It is rather complex obviously and using CE as a 'framework' for proof of concept saves me a LOT of time. If the concept is proven to work and accepted, it will be entirely recoded from scratch without all the nasty workarounds, and other such nastiness. That will, of course, also remove CE from the picture, as we can not use third party software at all for production purposes. However, as a tool to proof such a concept, CE is a magnificent platform, it could certainly be more reliable as it crashes a fair amount, but I am doing things with it that it was never meant to do really. It is not the 'host' for the universal device driver (well, there is no such thing, but lets just call it that, it is a bit more complex than that) but it does allow me to monitor things that other software (compare 'free' vs '6-figure price' here) does not let me, including Microsoft's own tools. It is also flexible enough so I can bend it to my will a little (there is one of those nasty things I mentioned). For something that is fairly unstable in certain areas it is also fairly easy to make it do something using bits of injected code and it is surprisingly stable in THAT regard.
| Quote: | Also, please report every minor bug, even if you think I already know them (There are some features I myself hardly use, like copy/paste)
And it helps if you also (or just) report them in the bugtracker.
That will be the first place where I look when starting on the planning and design for next version |
I will no doubt run into a LOT of bugs, bugs of the sort you never thought of when you coded CE, getting down to the very bottom of the barrel with Windows and especially device drivers tends to deliver VERY odd issues in both the 'driver host' as well as CE, which acts as the 'person looking over the shoulder of the host'. Generally these bugs aren't directly caused by CE, but are results of Windows doing something totally f'ed up and software with robust exception handling will bark, CE simply crashes (as do most of my own tools), that is, of course when Windows does not explode, which is fairly rare.
I can however pin point very easily what went wrong where and that could potentially help you make CE more stable.
Most of the time it is simply Windows that coughs up a lung (and a BSOD or three) because I did something that I shouldn't have (I have also identified some REALLY dodgy code in the Windows kernel which my work informed our Microsoft reps of, perhaps it'll get fixed, as of now, it works but is extremely sensitive to somewhat more 'experimental' code)
I'll make note of CE specific issues or observations and hand them over to you as I come across them, it's early in development and I am sure I will see many.
If 'the boss' doesn't mind, I can give you some more info on how I use CE, considering 'cheating' is not part of the design document. It is a whole other kind of usage, and extremely powerful when it comes to monitoring drivers and kernel (a lot of the kernel code is not CE code obviously, but it makes it much easier to develop such code. Kernel hooking isn't exactly a piece of cake, and that, in particular, is something that CE helps with, as hooking a bit of kernel code, isn't that hard, but try hooking a LOT of kernel code and squeeze that all through a few threads into a user mode application or five, in real time.
In fact, it has given me more ideas where CE could possibly help our conceptualizing processes (well, anyone's, really), but that's for the future, which could become quite interesting if all this works (you really don't want to know how much HARD WORK this is, I hate hard work).
Regards,
chASM
|
|
| 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
