The area you're looking at is something specific to the program; it's not part of Windows structures.
The value at fs:[0x2C] is the TLS array - array of pointers to the thread-specific blocks of variables somewhere in the program's memory. Here's how a typical TLS access to a __declspec(thread) variable looks like:
mov eax, DWORD PTR __tls_index ; load ...
When a debugger wants to attach to a process it will do the following things (see the DebugActiveProcess implementation on ReactOS):
Connect to the debuggee with DbgUiConnectToDbg
Tell the kernel to start debugging the process with NtDebugActiveProcess
Issue a DbgBreakPoint in the attached-to process with DbgUiIssueRemoteBreakin
The DbgUiIssueRemoteBreakin ...
I am Not Sure what you are looking for let me try
i have a dump file of a vm too MEMORY.dmp from a vm that ran xp sp3 created using .crash from a kernel debugger attached to it
i loaded it using windbg as below
windbg -z memory.dmp
now i thought i will count how many threads are running so i did some thing like this
kd> r $t0 = 0; !...
Disclaimer: The implementation of these APIs is likely to change between versions of Windows. I will be referencing 32-bit Windows XP SP3 in my answer. Your results may vary.
How thread creation works
There are three structures that must be initialized before calling NtCreateThread:
INITIAL_TEB: Contains pointers to the stack region
CONTEXT: Contains ...
Your intuition is correct. Changing the starting address of the Thread via SetThreadContext will change the entry point. Here is a C++ snippet to verify our claims
DWORD WINAPI orig_entry( LPVOID param)
MessageBoxA(0, "Original Thread Entrypoint called", "", MB_OK);
DWORD WINAPI ...
One of your problems is that you try to single step through Thread2 and you only refer to Thread1 in your code:
dbg.enumerate_threads() # <--- Return handle to the first thread.
In addition, the code the you posted is not reflective of the complete structure of your script, which makes it hard to judge wether you have other errors or not. You also ...
you mean the thread doesn't run when you have single stepped out of the CreateThread() call ??
if yes then the Windows Scheduler hasn't yet found time to Schedule your Threads Code
you can confirm when the code is run by Setting breakpoint on the LP_THREAD_ROUTINE
Argument passed to CreateThread() probably be in R8D in your screenshot i think
If your module is a DLL that is loaded dynamically by your executable, then Thread Local Storage won't be initialized on Windows XP for the DLL.
Quoting from my "Ultimate" Anti-Debugging Reference, section 4, page 25:
"On Windows Vista and later, dynamically-loaded DLLs also support Thread Local Storage. This is in direct contradiction to the existing ...
That should really say "the identifier of the process that is hosting the thread", since that's what it is. The snapshot that is created by the Toolhelp APIs is system-wide, so in order to understand where a thread lives, you need its process ID. That would be meaningless if it said process A, if process A created a remote thread in process B and then ...
By your description:
Yes, your program should have only one thread running, without debuger. You can check this on task manager.
However when you attach to windbg it will create a thread on break.
The third thread that you mention, i really dont have a clue. Maybe a injected dll running code...
But you can try to find out by opening the windows "call ...
Is there a way to go into the thread function, knowing only the thread
Yes, it's a 2-step process.
Step 1 - Convert the thread handle to a thread ID
In Process Explorer's menu bar, check the following:
View → Show Lower Pane
View → Lower Pane View → Handles
View → Select Columns... → Handle tab → check all checkboxes
Next, select your target ...
In addition to creating the child process, CreateProcess() also causes the creation of the child process's primary thread. Your post makes it sound like the calls to GetThreadContext(), SetThreadContext(), and ResumeThread() all act on that primary thread.
1st question: Why it is not in the list ?
As you said in your post, you are seeing the process's ...
Have you considered using the DLL only for providing "stub" methods, that you could call using CreateRemoteThread, and have the DLL methods transform the arguments into what the method you ultimately want to call takes?
I know this is not really a solution to how the program detects other threads running. But with some luck, the fact that your threads ...
Ok so ZwCreateThread has it in the context structure (PCONTEXT + 0xB0)
The api calls to receive the address are like this:
CreateSection(..SectionInformation..) - Probably to create to initial address
NtQuerySection(Handle, x, SectionInformation, x, x)
This SectionInformation is containing the address of the EntryPoint of the remote process, later ...
This is not anti-debug but the standard way the Win32 debugging API implements process attaching. The thread with DbgBreakPoint call is injected by the OS to ensure that the process gets stopped, since it could be in unknown state otherwise. Most debuggers should handle it transparently, but if yours does not, just set breakpoints on some APIs you’re ...
The act of injecting a thread will trigger a call to any Thread Local Storage callbacks which the PE file might carry, even when all other threads are suspended. Such a callback might be responsible for overwriting your thread code, since the callback has access to the important thread information such as its entry-point.
One method I tend to use (with IDA):
Run the binary (without a debugger).
Attach to it.
Take a memory snapshot.
Kill the process (from the debugger).
Re-analyse the whole database (i.e.: AnalyzeArea(MinEA(), MaxEA())).
You might need to find and rebuild IAT (Import Address Table). For this purpose, the IDC script "renimp.idc" comes handy.
After doing the ...
No. It is not necessary to create a connection with the CSRSS service in order for a process to function. The CSRSS server provides a few functionalities that are not needed for most processes, and therefore can be ignored unless it is requried in that specific process for any reason.
Since NT4, the main functionalities of CSRSS remained mostly the Windows ...
this doesnt have anything to do with stack size in pe header
assume esp = 1200cc
so ebp will also be 1200cc
sub esp,0xcc will make esp 120000
the three pushes will alter esp but not ebp
so edi will be 120000 after that operation
ecx = counter == 33 eax = 0xcccccccc
so rep stosd will fill the space from 120000 to 1200cc with 0xcccccccc
Everything seemed okay but it didn't stop executing the app at the
breakpoint. I guess it could be because of multithreading
No, it's unrelated to whether or not the process is multithreaded.
If you set a breakpoint and the debugger didn't stop at your breakpoint, it's because the instruction at that address never got executed or the breakpoint got ...
the start routine is called from pthread_start_thread() by an indirect call like
call [reg32 + const]
you can disassemble the function and confirm the register used and the constant used
in my dsl vm (very very old )
i see call [esi+0x8c]
gdb -q ./someexe
info symbol *( *(unsigned long *)($ebp +8) + 0x8c ) )
I'd be inclined to just use gdb to attach to the process, issue an info threads, select the thread with thread nn and do a bt. The function you want is the one called by start_thread(). Although, this will be in the start function, not the entry itself (although you could prob scan for a well known function prologue).