Im analyzing a particular malware sample and it seems to be doing the following in order to get write into the process memory of explorer.exe and execute code :-
OpenProcess(on explorer.exe)
NtAllocateVirtualMemory
NtWriteVirtualMemory
CloseHandle
CreateRemoteThread
WaitForSingleObject
GetExitCodeThread
Now what I wish to do is attach a debugger to the newly created thread in explorer.exe and debug it from its entry point onward. Would that be possible?
How could I go about doing the same?
You can run another instance of debugger and attach it to exporer.exe, then look address of thread function in CreateRemoteThread parameters, and set breakpoint there.
Related
I've got virtual machine with VirtualKD drivers installed and attached to windbg running on the host machine.
So far I've managed to set breakpoints on user-space processes by switching to the desired process context in the following manner :
# get procID
!process 0 0 myproc.exe
# use procID to switch context
.process /i <procID>
# continue till scheduler context switch to the desired process
g
# set break point on process' context (symbols should be visible)
...
the problem here is that the process must already be available (otherwise we won't be able to get its context).
Perhaps there's an easier way to state the process name in the breakpoint command with the ability to wait for the process to come up ?
EDIT :
Found out that with sxe ld myproc.exe I can get my breakpoint on process load .. However, in this stage, not all its libraries are loaded so I cannot set breakpoint on their method. Perhaps there's a way to get better notice when a library x.dll is being loaded in process myproc.exe ?
Put __debugbreak() into your code. Compile. Copy into VM. Run the exe with debugger attached. Once your code hit __debugbreak, it'll break you in windbg.
I have a thread that runs in a dll that I dynamic link with in my main app. Is there a way to wait for all threads in an .exe (including it's loaded dll's) without knowing the thread handle? Windows 7 x64, vc++
The thread is a function that does some processing on a certain file, it is not expected to return anything, it works upon a global class that is modified in certain stages of the thread completion. The thread function calls upon other functions .
I want to wait until the last line of the function is executed.
I never did this myself, but you could probably
create a snapshot using CreateToolhelp32Snapshot
then enumerate the threads using Thread32First and Thread32Next
for each thread ID, use OpenThread to aquire a handle. Make sure that you open the thread with the SYNCHRONIZE privilege so that you can, at last
pass all thread handles to WaitForMultipleObjects to wait for all of them to terminate.
Another solution, assuming that all you want is to stop the main() function from running but not exit the process until any other threads are complete, is to call
ExitThread(GetCurrentThread());
from within main(). If you don't call ExitProcess, either explicitly or by returning from main(), Windows will not exit until the last thread exits.
Note that there is a major problem with doing this, no matter how you approach it: if one of the Windows APIs you use has launched a thread that isn't going to exit, your application won't exit either.
The proper solution is for the DLL itself to contain a shutdown function that waits for its own threads to exit if necessary.
I've got a program that needs to be able to update itself. I have a second program that will perform the updates, downloading and installing. The updater will obviously need to be able to update the main program, and for that, the main program can't be running. So I want to have the main program launch the updater with a call to ShellExecuteEx, but the MSDN documentation has me a little confused.
It says that:
The SEE_MASK_NOASYNC flag must be specified if the ... process will
terminate soon after ShellExecuteEx returns. Under such conditions,
the calling thread will not be available to complete the DDE
conversation, so it is important that ShellExecuteEx complete the
conversation before returning control to the calling application.
Failure to complete the conversation can result in an unsuccessful
launch of the document.
And under SEE_MASK_NOASYNC, it says that the ShellExecuteEx call won't return until the operation is complete. What I want is to launch the updater and then immediately terminate the main program, so the updater can run without trouble. Is that the correct way to do it? And is there anything special I need to do to keep the launched updater from being marked as a "child process" that will be killed when the main process shuts down?
Do you have to call ShellExecute? I do something similar and launch via CreateProcess and it works fine.
(In reality, cmd.exe is launched which runs a batch file. The batch file waits, starts the updater and waits for it to finish, then waits a bit, then launches the main app again. Never had any trouble with it)
DDE won't be used to launch an EXE directly. (It's only used to launch certain types of files if they are regsitered as needing to be launched that way. If you're just running an EXE by name, DDE should be irrelevant.)
So you should specify SEE_MASK_NOASYNC (to make sure the ShellExecuteEx call finishes doing all it needs to do and your app is then free to end the thread as soon as the call returns) and the API should return very quickly.
here's a good CodeProject article about launching an updater:
http://www.codeproject.com/Articles/395572/Executable-Integration-Example-External-settings-a
I want to know how the mechanism of debugger injection works. Why is "Image File Execution Options" so special?
I have two guesses.
CreateProcess will call an internal function that checks against the list of registry keys. If it is found, then it manipulates the arguments and calls the debugger exe instead.
There is some other service listening for CreateProcess calls and intercepts them. It kills the original call or message (if createprocess is a message or message-like), then it runs the new process as if the original caller called it.
My desire is to verify and update components before an application starts. I like the IFEO "feature" but i need to run the original process after the verification step so I need a way to run it without recursing into the updater. I hope that by learning more about the injection system I can get this system working.
This article explains how it works.
In Windows XP and 2003 the user-mode CreateProcess code reads the registry and, if required, launches the debugger instead.
In more recent versions of Windows this functionality has moved into kernel mode.
But neither case seems to involve a general interception mechanism for CreateProcess.
This question already has answers here:
How can I use DebugBreak() in C#?
(5 answers)
Closed 2 years ago.
I'm using Windows Scheduler to run an exe I have written.
How can I jump into a debug session when the scheduler starts my exe?
Update 1.
I had thought of doing a Thread.Sleep and then Attach to Process. When I tried it, it says Debugger is already attached to process...
You could just call DebugBreak() from within your program.
According to the MSDN page, DebugBreak does the following:
Causes a breakpoint exception to occur
in the current process. This allows
the calling thread to signal the
debugger to handle the exception.
To cause a breakpoint exception in
another process, use the
DebugBreakProcess function.
You can then attach your debugger at this point, and continue running the program.
The only problem with this solution is that you need to make the DebugBreak() in the code conditional, so that it won't break every time the program is run. Maybe you achieve this through an environment variable, registry setting, or a parameter which the scheduler passes in to the program to ensure that it breaks when it starts up.
Example code
Here's some untested example code reading an environment variable:
int main()
{
char *debugBreakChar = getenv("DEBUG_BREAK");
int debugBreak = atoi(debugBreakChar);
if (debugBreak)
{
DebugBreak();
}
// Rest of the program follows here
}
Now all you need to do is set the environment variable as a system variable, and ensure that it's accessible from the same shell context as the scheduler (rebooting will achieve this):
set DEBUG_BREAK=1
Now the program will break on startup, allowing you to attach a debugger. Changing the environment variable to 0, or un-setting it, will allow the program to run normally.
Environment variables are a bit fiddly in this regard, as they are context-based and you need to know that the scheduler runs from the same environmental context. Registry values are better than this, and you can read a registry value using RegQueryValueEx in your code instead (you'll need to include windows.h to use this function).
Attach to Process will work (from within Visual Studio), although you may need to add a sleep statement at the beginning of your code if it is a fast process so that you can attach before it starts your main logic.
You can set a key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options that will attach debugger to the process when the process is launched. You can read how to do this in this KB Article.
There are couple of gotchas with this approach:
IFEO debugging does not work with pure managed debugging. You need to use Interop Debugging
You might need to remote your debugger to another session, depending on what user the Scheduler launches your app as.
To debug using VS, you need to actually specifyg VSJitDebugger.exe in the IFEO options for your executable. You will also have to specify the debugging engine to use manually. More details here.
"Attach to Process" in Visual Studio's Debug menu.