Posted: Wed Jan 26, 2011 9:58 pm Post subject: Trying structured exception handling to capture mem writes
Hi all,
I've been involved in trying to extend/modernize this (urls not allowed) first-person 3D RPG maker (Sword of Moonlight: King's Field making tool)
I'm trying to make some inroads into mucking around with the memory. For starters I'd like to add some basic arithmetic functionality to the event scripting/setup and fix some problems with the camera frustum which should also make wide screen resolutions more feasible.
A ton of work has been done so far working around the periphery, mainly spoofing libraries and hooking Win32 APIs.
Thing is there are known pointers in the .text section at runtime to various interesting bits of memory. For instance there is a pointer that points straight at the camera frustum shape. But changing the shape is no good because of timing concerns. Letting another thread overwrite the memory at random does influence what bits of scenery make it to the frame buffer.
I thought I had a clever angle of attack. I'd originally devised it for capturing writes to the in game registers (counters) authors use to store event flags/info... so like multiplication/division could be slipped in after the write. I've not tried that... because I stumble across the frustum, and thought that would be a more interesting initial proof of concept.
The idea was/is to keep the exe from writing its values into the frustum memory, so it would not overwrite the values we are storing there to in order to influence things.
So what I've tried is to take the pointer in the .text section, which is the only pointer aimed at this particular memory, and make it point to a newly allocated write protected region of memory.
Then register a "vectored handler" to catch the access violation / aim the write somewhere harmless and continue execution.
This all works fine in vitro. But the actual app never seems to follow the new pointer assignment...
I'm totally new to this kind of thing. But the thinking seems sound to me.
I've setup a fairly elaborate embedded memory inspector. It's plain to see the pointer in question is pointing to the right place. But the program basically doesn't seem to care that it's been redirected.
It just happily keeps writing to the same place. I'm wondering if the code is even executing in that memory or not... like maybe its cached or in a memory mapped file or something (which I've heard tangentially may be employed for executable code) with weird read/write semantics.
I know that the memory pointed to can't be known address wise prior to runtime.... so there must be some pointer to it... and there is only one pointer to it in memory. Therefore it seems like something fishy is up (which is probably over my head)
The exception handling stuff is pretty much irrelevant at this point, because the memory is not even being written where "it is supposed to be".
That said, I'm assuming exceptions will still fire for code that might not have been compile by an exception compliant/enabled compiler. I don't know for sure though.
I'm just about out of ideas in this direction. If you can set me straight one way or another please don't hold anything back.
I think You should check out where is the program getting the value of the pointer when the memory is accessed.
Set a breakpoint in that memory region and start checking where did it get the register values. Then You can find the pointer which is really used when the memory region is accessed by some code. _________________
How can I "put a breakpoint" into a memory region?
As in break when the memory is accessed? That's pretty much what I was trying to do with the exception approach. I don't know what code accesses the memory for the record. Catching it in the exception would reveal that, but that's not working.
PS: I'm assuming when the image is loaded the instructions don't get translated. Which if so the code would have to pull the address out of the memory at some point. It's possible it's accessed by a temporary variable but I'm assuming it would not be initialized with the original value if the thread is started suspended and the pointer gets overwritten before it's resumed.
Do we know for sure then the exe code actually gets executed in the .text segment versus being executed off in some cache somewhere that draws from the .text segment whenever it misses or something?
EDITED: I've also thought about maybe the compiler could've grouped a bunch of structures together in big blocks of memory so that the instructions are all setup with static offsets deep into those blocks. That sounds more like a 16bit compiler scheme, so I think it's less likely (but what do I know??) and anyway if the case that would render any attempt to move memory around pretty hopeless short of overwriting instructions en masse.
How can I "put a breakpoint" into a memory region?
As in break when the memory is accessed? That's pretty much what I was trying to do with the exception approach. I don't know what code accesses the memory for the record. Catching it in the exception would reveal that, but that's not working.
PS: I'm assuming when the image is loaded the instructions don't get translated. Which if so the code would have to pull the address out of the memory at some point. It's possible it's accessed by a temporary variable but I'm assuming it would not be initialized with the original value if the thread is started suspended and the pointer gets overwritten before it's resumed.
If the memory is not accessed when the program is running already, try to use "break on entry point". Olly will automatically break the program on the entry point if You start the program from Olly. CE also has this option, You need to use "Create process" for that. The only question is when is that memory region allocated. And how can You find it exactly to see if it is allocated already. But it seems You know the program already so maybe You know that already.
And both Olly and CE is supporting data/memory breakpoints so unless the memory is accessed by a 3rd application, You should be able to find it.
And if that pointer is not used, try to search for copies. Use CE and scan for values which are storing the same address as Your pointer. It has to get the value from somewhere obviously, so if not from Your pointer, than some other pointer which has the same value. _________________
I will have to become more proficient with "cheating" tools I suppose.
I'm curious myself how the breakpoints are implemented under Win32. I would checkout the CE source, but I understand (so says the download page) it's mostly Delphi. Will probably take a peek anyway sooner or later.
I assume you're making a debugger that pauses at every step of the way to see what's going on.
Full disclosure: this looked like a good place to ask these questions. But I think I'll have to become a CE user after all
PS: We're already using a custom launcher, so it may be necessary to integrate CE into that.
EDITED: I may've misspoken. May well be only the 5.5 sources include Delphi:
"Cheat Engine 5.5 sourcecode
(Note, big parts are written in Delphi)"
Last edited by H.D. on Thu Jan 27, 2011 7:08 pm; edited 1 time in total
I think that both Olly and CE is using debugger APIs. You can find tons of info about them on MSDN.
And no, the debugger is not pausing at every step. That would make it very slow. There are APIs to handle the exceptions caused by breakpoints.
Hmmm, I think because one of things that has been done to extend this software is to make it playable inside of a window most likely running CE alongside the original runtime won't be feasible because the app will be fullscreen/hogging the desktop etc.
I'd of course not be surprised if CE works totally fine with fullscreen only games, but I suppose I'd like an opinion before knocking myself out trying.
I'm curious if maybe there is a way to integrate CE into your own progam via like a .dll / api framework. But I suspect not because that's probably not what CE was ever thought to be used for.
I'm thinking I'll have to take the sources and integrate CE into our launcher as a kind of console. I was going to setup a console anyway. If no one much cares I might end up just building that around the CE sources...
Hmmm, I think because one of things that has been done to extend this software is to make it playable inside of a window most likely running CE alongside the original runtime won't be feasible because the app will be fullscreen/hogging the desktop etc.
I'd of course not be surprised if CE works totally fine with fullscreen only games, but I suppose I'd like an opinion before knocking myself out trying.
The CE debugger will stop the process but yeah, it will not jump to CE from the target application automatically. However You can configure hotkeys to do that and You can use hotkeys to run the process if it has been stopped. Of course the best way is to use the target process in windowed mode and not in fullscreen.
Quote:
I'm curious if maybe there is a way to integrate CE into your own progam via like a .dll / api framework. But I suspect not because that's probably not what CE was ever thought to be used for.
I'm thinking I'll have to take the sources and integrate CE into our launcher as a kind of console. I was going to setup a console anyway. If no one much cares I might end up just building that around the CE sources...
Dark Byte is the author of CE so He is the only one who can say "Yes" or "No" about this.
I don't think it would be such an impossible task, but I wouldn't do it without His permission. I guess it is polite to at least ask about it. _________________
Joined: 09 May 2003 Posts: 25854 Location: The netherlands
Posted: Thu Jan 27, 2011 8:38 pm Post subject:
The debugger routines of ce can be used without gui interaction if you use the lua scripting engine inside ce
(setbreakpoint and on breakpoint continue without asking for user interaction)
And such a lua script could theoretically be launched using a hotkey on a cheat entry that doesn't do anything
Quote:
PS: I'm assuming when the image is loaded the instructions don't get translated. Which if so the code would have to pull the address out of the memory at some point. It's possible it's accessed by a temporary variable but I'm assuming it would not be initialized with the original value if the thread is started suspended and the pointer gets overwritten before it's resumed.
Do we know for sure then the exe code actually gets executed in the .text segment versus being executed off in some cache somewhere that draws from the .text segment whenever it misses or something?
EDITED: I've also thought about maybe the compiler could've grouped a bunch of structures together in big blocks of memory so that the instructions are all setup with static offsets deep into those blocks. That sounds more like a 16bit compiler scheme, so I think it's less likely (but what do I know??) and anyway if the case that would render any attempt to move memory around pretty hopeless short of overwriting instructions en masse.
When windows loads an image it goes through the .reloc table which causes the code in the image to get updated to the new base address of the module.
Note that .exe files don't always come with a .reloc table so their static address pointers (e.g function table) will not get updated and you won't be able to find it either
example, the image is programmed to be loaded at 00400000
originalcode is:
The debugger routines of ce can be used without gui interaction if you use the lua scripting engine inside ce
(setbreakpoint and on breakpoint continue without asking for user interaction)
And such a lua script could theoretically be launched using a hotkey on a cheat entry that doesn't do anything
Quote:
PS: I'm assuming when the image is loaded the instructions don't get translated. Which if so the code would have to pull the address out of the memory at some point. It's possible it's accessed by a temporary variable but I'm assuming it would not be initialized with the original value if the thread is started suspended and the pointer gets overwritten before it's resumed.
Do we know for sure then the exe code actually gets executed in the .text segment versus being executed off in some cache somewhere that draws from the .text segment whenever it misses or something?
EDITED: I've also thought about maybe the compiler could've grouped a bunch of structures together in big blocks of memory so that the instructions are all setup with static offsets deep into those blocks. That sounds more like a 16bit compiler scheme, so I think it's less likely (but what do I know??) and anyway if the case that would render any attempt to move memory around pretty hopeless short of overwriting instructions en masse.
When windows loads an image it goes through the .reloc table which causes the code in the image to get updated to the new base address of the module.
Note that .exe files don't always come with a .reloc table so their static address pointers (e.g function table) will not get updated and you won't be able to find it either
example, the image is programmed to be loaded at 00400000
originalcode is:
So you seem to basically be saying here that the "literals" in the instructions can get translated? Or am I misreading.
So if like the .text section reported by like VirtualQueryEx reports the memory at 00400000 and there is corresponding memory there, is it safe to assume the code is executing there?
EDITED: Sorry, were you referring only to modules? There is not a .reloc section in the exe anyway. I was able to find out more about .reloc I think. Afaik, the loader won't attempt to reloc anything if the section is not present
I noticed yesterday the CE source seems to be alien to anything I know. Assuming it's Delphi as mentioned. I wonder if there'd be any use to writing a plugin for CE. I don't see any mention of that on the main site.
I am kinda interested to see what code is writing to that memory. I think just writing over code with nop instructions is pretty common practice, which I assume is done directly to the .text section at runtime... unless people are actually editing the .exe files before running them.
Still I wonder what that pointer is doing there in our case. I'm pretty sure it's initialized as soon as the image is loaded. I've zero practical experience with this kinda stuff.
EDITED: Most of manipulation we're doing happens from inside a .dll loaded into the exe's address space. Though the launcher does do a remote process write over some things, mainly the .dll strings.
EDITED: Would prefer to "double post" this, but maybe I'm wrong to think the code can be modified at runtime....
Because of the security implications of self-modifying code, all of the major operating systems are careful to remove such vulnerabilities as they become known. The concern is typically not that programs will intentionally modify themselves, but that they could be maliciously changed by an exploit.
I could load up the addresses I'm interested in, but CE didn't seem to have any tools to help me get further than where I'm already at.
I did not see any break on memory access features (which I did not think was possible anyway) so I'm assuming that was a misunderstanding.
The situation is basically I know where some structure is.
I get to it via a static pointer which is in the .text section.
But how then (if there is any way) do I find the code that accesses the structure in question?
I'd assume the program accesses the structure through that pointer. But overwriting the pointer has no affect, so it must not (unless something shady is going on)
CE btw can't seem to find the pointer in question. The ASM at the address of the pointer looks like the following:
0040389C - 00 12 - add [edx],dl
0040389E - 4C - dec esp
0040389F - 00 CD - add ch,cl
004038A1 - CC - int 3
004038A2 - CC - int 3
004038A3 - 3D C7050412 - cmp eax,120405C7
004038A8 - 4C - dec esp
004038A9 - 00 00 - add [eax],al
004038AB - 00 48 43 - add [eax+43],cl
004038AE - C3 - ret
004038AF - 90 - nop
004038B0 - 83 EC 40 - sub esp,40
004038B3 - 56 - push esi
But I'm virtually certain this is a misinterpretation / it's not code at all. Not the first 4 bytes anyway. Still if you think I'm misinterpreting code for a pointer, I'd definitely like to know thanks.
Can CE do a scan of the ASM and isolate instructions which seem interested in particular memory? I did not see anything like that.
That pointer will probably point to an area where data is stored, not to an are where codes can be found. Why would it need a pointer if the code itself is static?
ASM codes are usually stored on static addresses (unless it is a dll etc), while data is dynamic. _________________
The 004C1200 based addresses point to our memory. I guess scanning for the unaligned addresses in the opcodes and swapping them out or writing over them would do the trick.
Maybe we could just setup our own .reloc table
So what do you think the pointer (the original one in the top post) that seems to reliably point to the data base is?
Any advice for traversing the opcodes? Other than cracking an instruction set reference? Maybe a disassembler library? Are the opcodes aligned once in a while? They don't seem to be in general.
Thanks for the hand holding. Dunno what I'd do without it
EDITED: Also. I'm not 100% positive, but I'm pretty sure that the addresses baked into the opcodes can change from game to game (dealing with a game maker) and even play to play. Is that likely? And does it mean that the numbers are being translated at load time (probably something like your .reloc hint) ?
It might not hurt to check the numbers in the .exe tomorrow and see.
If so, and without an apparent .reloc table. Would that mean the loader is basically disassembling it to discover the addresses which require translation?
Last edited by H.D. on Sat Jan 29, 2011 10:58 pm; edited 1 time in total
It is a static address that will never change. The address, 004C1210 is part of the static game code (10124C00) which will not change with every execution, unless this is some very special program.
So whatever pointers are You changing in the compiled program, it will not have any effect. This code will always use 004C1210.
Codes that are using pointers are shown as
fstp dword ptr [eax]
or anything else that is not a static address. But if the code is already compiled with "fstp dword ptr [004C1210]", You can be sure that it will use 004C1210.
Quote:
EDITED: Also. I'm not 100% positive, but I'm pretty sure that the addresses baked into the opcodes can change from game to game (dealing with a game maker) and even play to play. Is that likely? And does it mean that the numbers are being translated at load time (probably something like your .reloc hint) ?
Check the exe file and You will find those bytes in the compiled code. It is not generated when You start the process, it is already coded in the exe file.
But as You can use the program to make other games, probably those games are re-compiled every time when You change something.
It may happen that when You create a game, the program is using those static addresses to get the values but they will be on other addresses in the compiled game. _________________
It is a static address that will never change. The address, 004C1210 is part of the static game code (10124C00) which will not change with every execution, unless this is some very special program.
So whatever pointers are You changing in the compiled program, it will not have any effect. This code will always use 004C1210.
Codes that are using pointers are shown as
fstp dword ptr [eax]
or anything else that is not a static address. But if the code is already compiled with "fstp dword ptr [004C1210]", You can be sure that it will use 004C1210.
Are you positive? I'm not sure I have enough long term experience with this particular memory. But I know some others would move around on us. I suppose they may be accessed by pointers. But I'm skeptical that's the case (they're surely not dynamically allocated) and I "know" they would move before we started locating them via the pointers in the .text section.
Quote:
But as You can use the program to make other games, probably those games are re-compiled every time when You change something.
No, it's not that sophisticated a game maker. The games always play via the same exe runtime. I'm not sure it would qualify as a "maker" if it was compiling stuff
Ah well, some progress on this front tastes good
Last edited by H.D. on Sat Jan 29, 2011 11:12 pm; edited 3 times in total
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
Reputation: 471
