I got a serious problem.
I need to log some information when a program reaches a specified code location. This code location is not the beginning of a (api) function or somethin, it is somewhere in the code section of the target program.
So i tried to write to this code location via WriteProcessMemory to insert a jump to another code location, which is actually some code i wrote into this process memory via VirtualAllocEx and WriteProcessMemory.

So i ran my program and what happened? The target program just closed itself. No error message, no system (fatal) error, no blue screen, nothin!
So i started the target program again, as well as my injection program and softice. i put a bpx on this code location before i started my injection program just to see that the program reaches the code location. it does. so i started my injection program, the bpx was still active and the target program again closed itself but the breakpoint wasnt caused. so i started the target program again, set a bpm on this code location, started my injection program and finally softice popped up.
actually it pops up 3 times before the program closes.

1) ntoskrnl!RtlSetDaclSecurityDescriptor
2) ntoskrnl!ProbeForWrite
3) ntoskrnl!RtlSetDaclSecurityDescriptor

Does anybody know anything about this kind of memory (write) protection? How does this program set it up? Or even how can i avoid it (if this is legal here)?

Any help would be greatly appreciated :)
Posted on 2004-09-10 10:35:29 by toxic
maybe i forgot to say that i did use VirtualProtectEx before WriteProcessMemory and both functions did not fail.
and before the program quit, i had a quick look at the address i was writing to but nothing changed, although WriteProcessMemory didnt fail..
Posted on 2004-09-10 10:54:39 by toxic
Could your program be in error? Maybe you're giving a wrong address or the wrong flags. Please post the part of your code that doesn't work.
Posted on 2004-09-10 11:37:37 by Sephiroth3
alright, i did it all over again. here are the facts and what i have found out:

somewhere in code section:
jmp @bla

push edi // size
push // src
add eax, esi
push eax // dest
call memcpy
mov eax, dword ptr <--- this is the code location

I need to log some information just right after the memcpy call.
I know that @bla is executed by some other code which is executed when i hit the left mouse button. i cant trace back the whole thing and since i only need to log information just right there, i dont need to.

Alright, what i do is insert a jmp to my code after the memcpy call.
After the WriteProcessMemory call in my program, the instructions after the memcpy call looks like:
jmp i32
where i32 is some 32bit value (its the correct rel. address of my code).
of course i saved the old instructions and i know how to continue the normal program after my code did the logging stuff.

Now, i just changed the program code to jmp to my code. As long as i don't do anything (e.g. hit the left mouse button) which causes this code location to be executed, nothing happens, the program runs smooth and no errors occur.
But when i hit the left mouse button, the program terminates BUT execution of code didnt even reach this code location. so my code wasnt even executed.
But this is the only code location i have written to, so i couldnt have made the program terminate.
The program must have terminated because something in the code section changed.

And if i set a memory breakpoint (not an execution breakpoint) on this specific code location, my debugger pops up. so something must access (read from) this code location to check whether it changed or not or somethin.

So, can i avoid this somehow?
Posted on 2004-09-10 15:06:18 by toxic
why don't you just hook the memcpy api???

or is it an "Inline" memcpy ???
Posted on 2004-09-10 15:35:58 by goggles99
i was already thinking about hooking memcpy as well. but the program doesnt import this function neither does it import msvcrt.dll.
so i'd have to write some functions to get its address, which wouldnt be too much of a big deal though.
but actually im very interested in how this program protects itself from WriteProcessMemory. this is something i just have to know :)
Posted on 2004-09-10 16:17:13 by toxic
I'm thinking it sets up a SEH early in the program execution.
From that point onwards, and this is all sheer guesswork, it uses deliberately bad code addresses, catches and processes its own exceptions, repairs the bad code address and so on, basically step-debugging itself without the debug api , without ints and without setting the TRAP flag.
Posted on 2004-09-11 03:03:13 by Homer
alright, thanks for the replies so far.

first of all, i wanna say that i cant hook memcpy, because the function call is not a call to memcpy, its a call to some local program function (my ida pro "thought" it was memcpy though).

what i tried next was writing a loader for the program, start it in suspended state, write my stuff to the code location and resume it.
loading the program, writing stuff to the code section both worked, but when i resume the program and program execution reaches a special point, the program also quits.

this tells me, that it cant be doing this kind of memory (write) protection by setting up some exception handlers, because the program doesnt even run yet when i write to the code section (it is still suspended). so it cant be using exception handling methods, right?

the program has 7 running threads and 1 timer with a delay of about less than 1 sec. maybe some of those threads or that timer do some kind of checking?

this program is killing me, help me please :)
Posted on 2004-09-11 06:36:16 by toxic
Maybe you could do trace execution from the window procedure, and try to narrow down where it quits (that's BMSG if you have Soft-ICE)
If you are using Soft-ICE, do you have the correct address space selected when setting the execution breakpoint?
Posted on 2004-09-11 07:04:24 by Sephiroth3
im 100% sure that i set the breakpoint correctly and tracing back from window procedure might be the very last option.

i just tried to change the instruction in the .exe file (i wrote an invalid jmp instruction to the corresponding address in the .exe pe file). the program started normally, i set a bpx on the address, but it was never raised. instead the program just terminated without any error msgs as usual.

so even if i change the instruction in the .exe file it knows that i changed something. wtf? how is this possible?

is there any other way of logging some information at a specific code location than inserting some code at this location?
Posted on 2004-09-11 09:23:13 by toxic
It sounds like it's calculating a checksum, but then it must have accessed the memory. Try setting a breakpoint on the location without changing anything, then when it reaches it, change the code and see if it still terminates when you click the left mouse button again. Also see if there is a difference when you use a hardware breakpoint instead of a INT3 breakpoint.
Posted on 2004-09-11 09:45:09 by Sephiroth3
I'm assuming your trying to write to code in another process. To Windows this is a big No No. What's probably happening is the system timer brings up the two debug exceptions DBG1 and DBG3 which gives control back to Windows and they don't allow this or if it were so you could write over the operating system it's self. There are proper ways to access another process. I suggest you take a look at Four-F's tutorial and it will tell you how to write a driver for some of these low level operations.


This is earlier post but should describe how to get around your problem.
Posted on 2004-09-12 09:41:22 by mrgone
I'm interested in knowing how you came to that conclusion. :lol:
Posted on 2004-09-12 13:08:35 by Sephiroth3
Was not familiar with" WriteProcessMemory". Did you use GetProcessId? Even if you did, how would you pass the parameter to other process without a driver?
Posted on 2004-09-12 13:38:58 by mrgone
Windows can use the "dirty bit" to check changes to memory. The processor always sets the dirty bit whenever memory is written too. Possibly since this is an active process it is part of Windows working set and could be subject to dirty bit checks.
Posted on 2004-09-12 15:11:51 by mrgone
if mrgone is right and its a lowlevel debug exception, then you should look at the cpu debug registers :) Sorry if I offended anyone.
Posted on 2004-09-18 06:11:11 by Homer
No, he just said that to sound smart :P
Posted on 2004-09-18 06:49:21 by Sephiroth3
No I just said that because I have read the pentium manual. Any time an area of memory is accessed the dirty bit is set by processor in the PDE or PTE. The PTE's and PDE's are cached into the processor TLB so it knows where to mark these memory tables.
Posted on 2004-09-18 20:35:39 by mrgone
A solution:
Use CreateRemoteThread to inject into the target process a Thread whose job is to spy on the target process.
That Thread now lives in the Process Space of the target process, but ALONGSIDE the real thread(s) of the target process.
It has full access to all the memory of the target process WITHOUT need to modify anything. It should now set the the privilege on the legitimate threads to very low so that it gets more execution time, and reduce the chances of 'missing the phish'.

Sorry if I offended anyone :)
Posted on 2004-09-18 20:42:35 by Homer