I noticed that DebugActiveProcess let your process be a debugger to another process.
I saw that this function let you know the following events of the debuggee : Exception, Createthread, CreateProcess, ExitThread, ExitProces, LoadDll, UnloadDll, OutputDebugString.
My question is if we can write to the memory of the debuggee process without WriteProcessMemory? Is the debugger exists in the context memory of the debuggee?
Thanks!
A debugger exists in a different process from its debuggee. So you will need to use ReadProcessMemory and WriteProcessMemory to access the debuggee's address space.
Unless you inject code into the process you're interested in, those are two different processes: one is the debugger and one is the debuggee.
You can either launch the debuggee via CreateProcess(cfr. process creation flags) or attach your debugger to an existing one but they remain two different entities anyway and you'll have to use WriteProcessMemory to write to it.
It's the operating system which provides the API to operate your debugging on the target process (and you should make sure you have privileges to do that).
Related
I'm trying to write a utility that allows me to read the memory from a process that is currently running in windows. I have used CreateToolhelp32Snapshot to build a current PID list for all programs running on the computer and I open a handle via OpenProcess with the vm_read flags without any issues. The roadblock I am running into is the readprocessmemory function of the windows API fails to read anything if the base address given is not currently readable. That being said what method can I use to determine the readable sections of a process.
My only idea on the matter is that I could iterate over the readprocessmemory function starting at the midway point of (size of process in memory)/2 and continue until I find the specific location that will allow me to read but I believe this would be terribly inefficient for large processes (o(n/2)), and even if it is the only user-mode option how would I even find the total size of the process in memory?
If this question is not meant for stackoverflow let me know and I will close it, please do not down-vote me I have been attempting to solve my problem myself for several hours now.
You can call VirtualQueryEx for each range of pages in the address space to find out if the address is in use. If the other process is not suspended then there will obviously be a chance that a pages status changes between your query and read operations.
My program works flawlessly on Windows Vista Ultimate and Windows 7, however it fails on Windows XP.
First, my application creates a process of a system file, it calls GetThreadContext(remote_thread) and sets an LPVOID value to the value context->Eip, and then checks the values in the structure MEMORY_BASIC_INFORMATION set from VirtualQueryEx.
Here are the values VirtualQueryEx returned when called:
Windows XP
0 - allocation base
0 - allocation protect
2088828928 - base address
1 - protect
983040 - region size
65536 - state
0 - type
Windows 7
2003959808 - allocation base
128 - allocation protect
2004025344 - base address
32 - protect
876544 - region size
4096 - state
16777216 - type
Windows Vista
2006122496 - allocation base
128 - allocation protect
2006536192 - Base address
32 - protect
389120 - region size
4096 - state
16777216 - type
Why is it that when I run my application on Windows XP it has no allocation base and no allocation protect, as well as completely different values to Windows 7 and Windows Vista.
I plan to use VirtualProtectEx on the address (context->Eip), so If those are the values on XP then VirtualProtectEx will inevitably fail, as I would be accessing unaccessible memory.
Here is how I create my process :
if ( CreateProcessW(m_pwszContainerPath, NULL, NULL, NULL, FALSE, DETACHED_PROCESS | CREATE_SUSPENDED, NULL, NULL, &m_stStartInfo, &m_stProcessHandles) == TRUE )
{
// Get context of thread
m_stContext.ContextFlags = CONTEXT_FULL;
if ( GetThreadContext(m_stProcessHandles.hThread, &m_stContext) == FALSE )
goto _CLEANUP;
// Grab, Eip
m_pvLdrInitEip = (LPVOID)m_stContext.Eip;
}
The fact of the matter is: This works flawlessly on both Windows 7 and Windows Vista.
Is there something I am missing here?
Thank you for any help.
EDIT - Here goes a picture :
Here is a picture of two instances of olly running the executable, one in the XP virtual machine, one outside. From what I notice, the XP picture (bottom one) has it's EIP set to ModuleEntryPoint while the Windows 7 Instance has it set to ntdll..
I investigated further, and found that the EIP was, in fact in kernel32.dll image (on Windows XP), rather than ntdll.dll as it should be..
Creating a process with CREATE_SUSPENDED means the main process won't finish it's initialization before you run your code. the way the loader is implemented causes the different effects between XP and Vista/7, and since the CREATE_SUSPENDED documentation doesn't grantee any process initialization you can't really count on that method. the CREATE_SUSPENDED flag only states the process is created with the main thread suspended.
It's not exactly clear what the OP desires to accomplish, but a few methods to achive similar goals come to mind:
Write a debugger instead of remotely manipulating another process. a simple tutorial and code examples can be found Here. the debugger gets an event for every spawned thread, you could probably use that.
Modify the PE to execute your code before any other by either creating a new section for your code and placing a TLS entry in the PE to execute code inside the process's memory space. you're code will then run before the process's EntryPoint but after it was initialized.
Modify the PE and replace the EntryPoint in the PE header with your own code, just make sure you execute the original entry point yourself. some initalization will be missing but all the PE code sections will be loaded.
Inject a DLL into the process's memory address by either creating it suspended and loading a DLL from a different thread, or any other method. This article lists a few and you can Google for more. i'm not sure that'll work in all cases if you want to get the process initialized because of similar issues, but I do think that calling LoadLibrary will get you the desired efect. That is also a clean way to get code into another process and manipulate it while being more stealth than using a debugger.
You can also try scanning the entire memory for the code chunks you want to manipulate while the process is suspended, that might also work on XP.
You could try creating the process unsuspended and let it run for a short period of time before suspending the threads. after timing and a few tests you'll get a resonable feelling about how much time it takes to initialize. That's a bit risky but might work.
creating a debugger will be the easiest and most robust/generic method but will have the disadvtange of being easily detected (although you could use anti-anti-debugging tricks). loading a DLL will be the best way if you want to remain undetectable by the manipulated process (if it has any anti-debugging tricks) if you want more suggestions or recomendations for your specific needs please edit and describe in detail what exactly you want to accomplish as it is not clear from your question. a little more details about the program (is it native, or .net for example) would also be helpful.
EDIT:
another speculation suggested by friend was that the kernel did not finish the process initialization by the time the syscall returns and you call VirtualQueryEx. he said calling WaitForSingleObject on the process's handle will return once the process is fully initialized and you could access all the information and resume the execution afterwards.
CreateProcess(CREATE_SUSPENDED) only do partial initialization. You may try to VirtualAllocEx() the EIP region and explicitly COMMIT it, and then VirtualProtectEx, of course this is a quick hack, you can have a test, I'm not sure whether this can
fix the problem. BTW, what's your real purpose to do so? If you intend to hook at early stage of process execution, patch the entry point of PE header is better, since when instruction control flow reach the entry point, the process must have completed its initialization, however this also has its downside, e.g. TLS callback is invoked before the entry point get executed.
Is there any way to detect process crash in windows 7 ?
Just to clarify, upon every process crash windows creates the WERfault.exe ( windows error reporting) . I have driver which monitors the system by using the existing kernel callback mechanism of the kernel. The callback notifies my
driver when a certain process event happens (using PsSetCreateProcessNotifyRoutine).
The problem is I see that WERfault.exe created by svchost.exe but I can't find a way resolving which process has crashed.
Setup your application as the automatic debugger. This can then pass the event on the the real WER if you want to provide the usual UI.
->Is there any way to detect process crash in windows 7 ?
Yes, you can use AdPlus script can be used with command line.
it can be use with windbg go for the documentation i think it may solve your problem.
Adplus dump all your process memory into a file .
I want to create 5 child process in Windows using C++. But I am confused that CreateProcess asks for lpApplicationName and not like fork in which I can figure out whether I am child or parent. how to do this in Windows
Unfortunately the CreateProcess function can only be used to load a program and start a new process for that program.
You can however use CreateProcess to simulate the fork functionality, by asking it to load the program you are already running, and then ask it to jump to the correct position. This is what is (or was, at least) done by Cygwin, as referenced by this old answer.
It is usually preferable in Windows to use threading rather than multiple processes, because processes are much heavier objects in Windows than in UNIX.
However, you can do what you're asking by passing the name and path of your application to CreateProcess (using GetModuleFileName if you don't already know it) and including a command-line argument to tell your application that it is being launched as a child process.
Keep in mind that the child processes will be started from scratch, they will not have a copy of the parent's memory as they would if you were using fork.
Is there a way (in C++ & windows XP) to detect if one process spawns any other processes?
for example,
write.exe in system32 spawns wordpad.exe then disappears, is there a function that tells me if the process is about to do this?
for those interested i solved the problem using this section of msdn:
http://msdn.microsoft.com/en-us/library/aa390425(v=VS.85).aspx
Nothing in the Win32 API for this. However, it is supported through WMI with the Win32_ProcessStartTrace query. You'll find some C# code that demonstrates the query in my answer in this thread. Writing WMI code in C++ is fairly painful, you'll find a link to boilerplate code you have to write in the MSDN Library article.
Do beware that this isn't particularly fast. It isn't clear to me how much help the WMI provider gets from the kernel to generate the notification but given the speed it quacks like polling. In other words, the process is likely to be well on its way by the time you get the notification. This is otherwise par for the course on a multitasking operating system.
You can enumerate over the process tree, which identifies running processes and their parents. This is the inverse of what you want (you want to identify child processes, not parent processes). But of course by keeping track of parent process IDs while enumerating, you can identify which sub-processes a given process has spawned.
To do this, call CreateToolhelp32Snapshot and then use Process32First and Process32Next to enumerate the processes. The enumeration will fill in a PROCESSENTRY32 struct that contains a th32ParentProcessID member.
This is a polling method; there may be another way of actually hooking the CreateProcess function, but I don’t have any information about that.
I think you would need to make a global hook DLL that attaches itself to every running process. DLL then finds a place where a function call to CreateProcess is mapped to actual CreateProcess from kernel32, and change a table entry to redirect the call to it's own code to "detect" the call to CreateProcess. All this assuming that some user firewall will not prevent your global hook from executing.