Hi. I've been writing C++ for several years, but this is my first time reversing and I'm a bit stuck. Sorry if this question's already been asked, but I didn't really know what to look for.

What I'm trying to do is take same value in the program (say, the contents of eax) and log it somewhere so I can know what possible values it can take, or how it changes in time.
This was my idea:
1. Take a somewhat useless function and use it to insert my own code.
2. Before main is called, call LoadLibrary() and GetProcAddress() to load the code that will do the logging (this is to give myself some breathing room, plus allowing me to change the code without patching the executable).
3. At the relevant locations, redirect to the patched code and call the function returned by GetProcAddress(), always ensuring that the state of the original location is preserved.
Now, my problem is that I couldn't find where to store the function pointer. That made me fall back to a LoadLibrary-GetProcAddress-FreeLibrary cycle every time I want to call the function. I may at one point need to keep state between calls, so this is no good, plus I expect that I'll use the function in locations that are called up to 60 times per second, so I'd like to eliminate as much latency as possible.

Any thoughts on where to keep the pointer?

If instead of watching a register you're okay with just watching memory, the easiest solution would be to use http://www.cheatengine.org or http://www.memoryhacking.com.

No good. I really need to be able to log any value in the program.
For example, take a look at this call:

In this example, I'd like to know whether edx ever takes a different value. If it doesn't, that means the class is unnecessarily polymorphic.

Hi,

Just to eliminate the method, is there a reason you don't want to use a debugger? Most of them have the ability to log data at specific addresses, so is the simple solution. Unless of course there is debugger detection you can't get around or the code is dynamically generated (is within an encrypted block) and breakpoints won't stick, or you think a debugger tracing will bog down on the fast loops you expect, or... whatever.


I know you said you didn't want to patch the executable, but that's the next easiest solution. If it's just general code and you don't have to worry about difficult checksum checks, a standard hard coded redirected patch should work. You can create your own section, use inline data definitions, add imports to work with a log file, etc. The following is a handy utility for that:

http://www.woodmann.com/collaborative/tools/Code_Snippet_Creator_(Iczelion)


If dynamic patching is required, I'm sure there are tutorials around for that as well, but it would be good to know more about the type of code you're working with and why the other solutions aren't really suitable or desired.

option #2. install a veh/seh that handles page faults for PAGE_NO_ACCESS then
protect that area you wish to watch,make the handler routine for the exception 'gather' the info you need and make it recognize 'already' processed data...

option #3 make a emulated debug-like environment using direct reads of process memory and liberal usage of Suspend and Resume thread o0..

option #4 a Dynamic Binary Instrumentation Engine.. I have so much to learn on this.. :[


I lost the rim of the box ...maybe, on this one.. use the above idea for Exception Handling and "Patch the Forward Execution flow" at 'watched' locations and 'contexts'..maybe a slicer or sorts, this should be done in memory prior to executing next opcode, and triggered on next opcode, but im sure a quick 'flash' of memory and modification of protection to allow normal execution of 'code area' then a quick reflash back to original code in memory at just outside the executing area by another exception..

>>Any thoughts on where to keep the pointer?
Increase the virtual size of the .data section in the target's PE header
or use a value just at the end of it cause PE sections are normally allocated in chunks of 0x1000

As aqrit mentions above, such "code caves" are usually fine for storing smaller data pieces like a few pointers or so, but the "proper" way (which has also practically no limit in the size of stored data) is VirtualAlloc() and friends. But then again, you'd have to store the pointer to that buffer somewhere, but at least you're unlimited in size then, and only need to store that pointer in a data section code cave.

BUT, if you're already dynamically patching the code of the app in memory to begin with (i.e. to insert your hook), why not just hardcode a call to the dynamically resolved function address to begin with a that point?

You might also find some of the following tools helpful in the hooking/dynamic-patching process:

http://www.woodmann.com/collaborative/tools/Category:Code_Injection_Tools

Also in the ArbitraryUserdata in the teb...in the tls expansions slots..many places..

Skyphers site is pretty good for the peb teb.

Logging is just one of the things I want to do. At one point, I'd also like to send values to a console in real time. The overhead from the debugger is also a concern.

I thought of that, too, and realized I was just moving the problem. With VirtualAlloc(), I could request specific memory addresses, but it seemed a bit unreliable. Plus, allocating a whole page just for a single pointer is silly.

That sounds like a good idea. One question, though: OllyDbg reports the section as read-only. Can I write to it anyway?

What "debugging overhead" are you concerned about? If you're using OllyDbg or IDA, there is no overhead. If you're writing your own, the overhead is minimal.

I would suggest you use OllyDbg's conditional logging breakpoints. If that's not powerful enough for you, write an OllyScript or an IDA Pro debugger script.

In the near future will be posted the concept of protection that will be useless detectors and logging.

Aw, hell.
Thanks.

I would still like an answer to my last question, though.

Just use VirtualProtect() in your initial hooking code, and you'll be fine.

And again, since you're now already messing around with both changing memory protection settings and live patching the code section (which also normally requires changing memory protection settings, unless some packer or similar didn't do it for you already, so I'm a bit surprised by your question?), the cleanest way would probably be to just patch an absolute call into the hooked location, as I mention above. The "code cave" / "data cave" method will after all fail at those times the original size of the target section is within three bytes of the alignment boundary.

If you're writing to it via OllyDbg's UI, then yes, you can just go ahead and write to it. Olly will take care of the page protection issues.
If you're writing to it via your own program then you'd need to use VirtualProtectEx(...) to change the page protection to make it writable.