I am debugging a malware do injection to Notepad.exe use following approach:
CreateProcess(notepad.exe , create_suspend)
GetThreadContext
VirtualProtectEx
WriteProcessMemory(address=1000000, Size:10200)
WriteProcessMemory(address=7FFD8008, Size:4)
SetThreadContext
ResumeThread
There is no pid to attach Notepad.exe to debugger before it resume.
after resume, the thread run so fast that I can't attach to ollydgb in time.
I Dump memory and save it as PE from what it write to Notepad.exe,
but it run with error.
so how to debug malware injected code? thanks!!
You should modify the first byte of the injected code to 'int 3' (opcode is cc) before invoking WriteProcessMemory.
OD can't attach to the process that hasn't started the main thread, use WinDbg instead.
Invoke ResumeThread after WinDbg is attached to the subprocess.
Press F5 to let the main thread run.
The main thread will stop when it sees 'int 3', now you should change the byte to the original value. For example: eb addr_to_change 55. PS: opcode 55 means 'push ebp', which is the most common instruction executed at the beginning of one function.
Now, Press F10 to start single-step debugging.
After CreateProcess returns, the process should already exist and you should be able to attach to it. Another approach is to skip the ResumeThread call and attach at that point.
Related
I am writing a simple debugger for learning purposes. I need to know where the Initial Breakpoint set by Windows is located to handle it properly. Read somewhere that is should be at the function DbgBreakPoint() from ntdll.dll, however that function resolves to address 0x77ab0a60 and from my tests the Initial Breakpoint always raises at address 0x77aedbcf. Is this a function or just some random address with an INT 3 instruction? If I am not mistaken ntdll.dll is always loaded at the same address, if so do programs always break at this exact address, or is there a variation?
process in user mode begin execute from LdrInitializeThunk, it call LdrpInitializeProcess. this routine, after load all static dependencies but before call it initialization routines - check are debugger present (BeingDebugged member of PEB) and if yes - call LdrpDoDebuggerBreak where exist int 3 instruction. in case wow64 process the LdrpDoDebuggerBreak will be called 2 time - from 64 and 32 bit dll. as result 64-bit debugger got 2 breakpoints - STATUS_BREAKPOINT and STATUS_WX86_BREAKPOINT.
how handle this - already debugger must select yourself. interactive debugger simply stop here. another debugger tools, usually simply skip(handle) first STATUS_BREAKPOINT (and STATUS_WX86_BREAKPOINT) by returning DBG_CONTINUE
I'm ptracing a multithreaded application and 9 out of 10 times, the breakpointhandling works just fine, but sometimes i get a SIGCHLD event instead of SIGTRAP.
This is the sequence:
application is running, main thread hits INT3
debugger's waitpid returns SIGTRAP
debugger SIGSTOPs all threads that are not already "t (tracing stop)", using tgkill
debugger runs ptrace(PTRACE_SINGLESTEP) on INT3'ed thread (after fixing RIP and 0xCC byte)
debugger waitpid's and expects SIGTRAP, but gets SIGCHLD instead
What am I supposed to do with this SIGCHILD? Ignoring it makes the debugger stuck forever in following waitpids. Injecting it back into the debugee with PTRACE_CONT screws with the initial PTRACE_SINGLESTEP.
It seems that it is happening only for main threads (PID==TID), not for childthreads (aka LWP).
I'm using UBUNTU 12.04 64bit in virtual box.
Injecting SIGCHLD with PTRACE_SINGLESTEP (data param) back into debugee seems todo the trick.
I've tried to set breakpoint on every function that makes any sense but program exit before reaching any of those. Is there a way to make program run in step-by-step mode from the start so I can see what's going on?
I'm trying to debug /usr/bin/id if it's important (we have custom plugin for it and it's misbehaved)
P.S. Start command doesn't work for me here(it should be a comment, but I don't have enough rep for it)
Get the program entry point address and insert a breakpoint at that address.
One way to do this is to do info files which gives you for example "Entry point: 0x4045a4". Then do "break *0x4045a4". After run-ning program, it will immediately stop.
From here on you can use single stepping instructions (like step or stepi) to proceed.
You did not tell what system you are trying to debug. If code is in read-only memory you may need to use hardware breakpoints (hbreak) if they are supported by that system.
Use start command
The ‘start’ command does the equivalent of setting a temporary breakpoint at the beginning of the main procedure and then invoking the ‘run’ command.
e.g.
a program with debug info main, and usage like this: main arg1 arg2
gdb main
(gdb) start arg1 arg2
Use starti. Unlike start this stops at the actual first instruction, not at main().
You can type record full right after running the program. This will record all instructions and make them possible for replaying/going back.
For main function, you'd need to type this before reaching the breakpoint so you can set an earlier one by break _start -> _start is a function always called before the standard main function. (apparently applies only to the gcc compiler or similar)
Then continue to main breakpoint and do reverse-stepi to go exactly one instruction back
For more info about recording look here: link
When debugging a Windows process, it would sometimes be convenient to break as early as possible.
Inital Callstack looks like this: (you get this e.g. when you set a breakpoint in a DllMain function on DLL_PROCESS_ATTACH)
...
ntdll.dll!_LdrpCallInitRoutine#16() + 0x14 bytes
ntdll.dll!_LdrpRunInitializeRoutines#4() + 0x205 bytes
> ntdll.dll!_LdrpInitializeProcess#20() - 0x96d bytes
ntdll.dll!__LdrpInitialize#12() + 0x6269 bytes
ntdll.dll!_KiUserApcDispatcher#20() + 0x7 bytes
so setting a breakpoint in one of these ntdll routines should really break the process very early.
However, I can't figure out how to set a breakpoint there prior to starting the process in the debugger. Is it possible in Visual Studio (2005)? How? Can it be done in WinDbg?
I would use something like GFlags to launch the debugger when the process starts.
Here is a sample gflags settings for test.exe
And here is the debugger output. Notice the call-stack with ntdll!LdrpInitializeProcess
CommandLine: "C:\temp\test.exe"
Symbol search path is:
srv*;srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad:
0000000000d20000 0000000000d28000
image0000000000d20000 (1b40.464):
Break instruction exception - code
80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
0000000077c7cb60 cc int
3 0:000> k Child-SP RetAddr
Call Site 000000000012ed70
0000000077c32ef5
ntdll!LdrpDoDebuggerBreak+0x30
000000000012edb0 0000000077c11a17
ntdll!LdrpInitializeProcess+0x1b4f
000000000012f2a0 0000000077bfc32e
ntdll! ?? ::FNODOBFM::string'+0x29220
000000000012f310 00000000`00000000
ntdll!LdrInitializeThunk+0xe
Or you could open the process within the debugger like Windbg which would break into ntdll!LdrpInitializeProcess by default.
HTH
I have found out how to do it in Visual Studio.
The problem here is, that setting a breakpoint in any assembly function will be remembered as a "Data Breakpoint". These breakpoints are disabled as soon as the process stops, so even if I set one in this function (I can do this because I have the function on the stack if I set a breakpoint in any DllMain function) this breakpoint will be disabled for a new process run.
However for ntdll.dll (and kernel32.dll) the load addresses are pretty much fixed and won't change (and least not until reboot).
So, before starting the process, I just have to re-enable the Data Breakpoint for the address that corresponds to this NtDll function and the debugger will then stop there.
I'm dealing with an anti-debug application which disables EXCEPTION_DEBUG_EVENT from being passed to my debugger, instead it executes its SEH and UnhandledExceptionFilters.
I tried it with 3 different debuggers (even selfmade one)
My debugger receives other debug events like LOAD_DLL, CREATE_THREAD etc
Exceptions are not passed when first chance debugging aswell as last chance
Breakpoint events of my own created threads get passed to the debugger, so the anti-debug method must be thread specific and may be a modification of the ThreadInformationBlock
There's no kernel mode access
So how can it be possible in usermode to pass EXCEPTION_DEBUG_EVENT (for only one thread, not affecting the whole process) ?
Well.. the solution is rather simple:
call
NtSetInformationThread(
IN HANDLE ThreadHandle,
IN THREAD_INFORMATION_CLASS ThreadInformationClass,
IN PVOID ThreadInformation,
IN ULONG ThreadInformationLength );
with ThreadHideFromDebugger ( 0x11 ) as ThreadInformationClass.