Results 1 to 13 of 13

Thread: Attach Extended

  1. #1

    Attach Extended

    Hi all
    This is a really small plugin that I have written for improving attach feature of OllyDbg.
    With this plugin,you can attach to process by identifing its PID directly,not only selecting process list. In addition,you can find PID of process by dragging a small cursor on each window(This can be used on some protection which remove process from process list like GameGuard).

    Please let me know about Bugs, and your suggestions for more process attaching options.

    Regards
    Attached Files Attached Files
    I should look out my posts,Or JMI will get mad at me! ;)

  2. #2
    A possible extra feature would be anti-anti-attach. There are various ways a protection system can detect and even prevent a debugger attaching to it, and there are also various ways to counter these tricks. You could look into this subject and automate the countermeasures in your plugin, completely transparently (ie the plugin simply kills/circumvents any anti-attach when attaching, without the reverser even having to know there was an anti-attach at all).

    nezumi documents some interesting techniques in the Blogs forum. There also exists a plugin called AttachAnyway which kills some anti-attach methods, but not all.

  3. #3
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    Hey Hero, can it attach to (not yet ResumeThread'ed) processes created with the CREATE_SUSPENDED flag, unlike normal Olly? That would be really great...
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  4. #4
    Quote Originally Posted by arc_ View Post
    nezumi documents some interesting techniques in the Blogs forum. There also exists a plugin called AttachAnyway which kills some anti-attach methods, but not all.
    I will try to read it in blog,and add it to this plugin on my free time.

    Quote Originally Posted by dELTA View Post
    Hey Hero, can it attach to (not yet ResumeThread'ed) processes created with the CREATE_SUSPENDED flag, unlike normal Olly? That would be really great...
    hmmmm
    I think this will be a good feature too,but is it possible in theory at all?
    If process has started in debug mode,in addition of suspended mode,i think we cannot attach it,because as I know we cannot debug a process which is debugged. But perhaps it is possible on a non-debugging suspended creation process.
    I should test if I can attach to a suspended process at all,if yes I surely add it.

    Regards
    Last edited by Hero; March 4th, 2009 at 15:35.
    I should look out my posts,Or JMI will get mad at me! ;)

  5. #5
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    It should absolutely be possible (from a Debug API viewpoint) to attach to a process created with the CREATE_SUSPENDED flag, it's just a bug in Olly that it can't do it I think.

    It would indeed be great if you could add it.

    I also added it to the CRCETL, please feel free to update its entry as soon as you release an update (and also specify the version number, which I left out because I didn't know it):

    http://www.woodmann.com/collaborative/tools/index.php/AttachExtended
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  6. #6
    Quote Originally Posted by dELTA View Post
    It should absolutely be possible (from a Debug API viewpoint) to attach to a process created with the CREATE_SUSPENDED flag, it's just a bug in Olly that it can't do it I think.

    It would indeed be great if you could add it.

    I also added it to the CRCETL, please feel free to update its entry as soon as you release an update (and also specify the version number, which I left out because I didn't know it):

    http://www.woodmann.com/collaborative/tools/index.php/AttachExtended
    Hi dELTA
    I checked olly and noticed that it cannot attach to a suspended process because DebugActiveProcess fails.
    Further check shows that in DebugActiveProcess fails at DbgUiConnectToDbg in this line:
    Code:
    .text:7C950691                 xor     ecx, ecx
    .text:7C950693                 mov     eax, large fs:18h
    .text:7C950699                 cmp     [eax+0F24h], ecx
    .text:7C95069F                 jnz     short loc_7C9506D5 <-this jump occurs
    As I remembr,FS:18h contains information for thread,isn't it? Anybody knows what is that data in [eax+0f24h] for?

    Edit1: I was WRONG, because after testing on another computer,I noticed that problem is not here,don't know why my other PC was failing here,but it seems I was wrong.
    Edit2:Found a bug in olly which prevents to attach suspended process. Trying to solve it now(donna if it there is more bug,but this one is sure) :P

    Regards
    Last edited by Hero; March 5th, 2009 at 12:27.
    I should look out my posts,Or JMI will get mad at me! ;)

  7. #7
    OK,now I need to get some help....

    After checking olly,I noticed a problem that cause olly crashs when you attach to a suspended process.
    This happens because you CANNOT get list of modules from a suspended process using EnumProcessModules.
    I searched internet and noticed that when you create a process as suspended, it has not informed for its module list by csrss yet,so EnumProcessModules will fail.
    I tried to read them directly from PEB of process,but I noticed that PPEB_LDR_DATA field of PEB which contains information for modules is NULL for suspended process.
    Any idea how I can get module list of a suspended process?
    Do you think kernel's EPROCESS structure contains a valid data?
    If there is an article how process modules will load in process by csrss,it will be great help too.
    You will see same problem when you try to explore a suspended process with ProcessExplorer too for same reason.

    Regards
    Last edited by Hero; March 6th, 2009 at 02:51.
    I should look out my posts,Or JMI will get mad at me! ;)

  8. #8
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,048
    Blog Entries
    5
    Ok, since you're doing funky stuff how about a funky idea? No idea if this will help with the problem, it's just a hack-and-see thought at the moment.

    PEB / PEB_LDR_DATA doesn't get fully initialized until ntdll!LdrpInitializeProcess is called.

    http://www.openrce.org/forums/posts/594

    LdrpInitializeProcess is called as an APC, which from all accounts won't happen until ResumeThread is called.

    http://www.woodmann.com/forum/showthread.php?t=11154


    There is a function called Nt/ZwAlertResumeThread, which maps to nt!_KeAlertResumeThread.

    http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtAlertResumeThread.html

    Code:
    NtAlertResumeThread(
    
      IN HANDLE               ThreadHandle,
      OUT PULONG              SuspendCount
      );
    
    
    ThreadHandle
    Handle to thread object.
    
    SuspendCount
    Returns number of suspend request for thread ThreadHandle 
    before call NtAlertResumeThread.
    If this number is 0, thread will continue execution.
    
    
    Difference between AlertResumeThread and ResumeThread:
    the first one sets Thread Object to alerted state 
    (so before thread will continue execution, all APC will be executed).

    The idea here is to execute the outstanding APC which will call LdrpInitializeProcess, without actually resuming the process.

    So find the starting thread valid handle of the suspended process, EPROCESS.ThreadListHead might work.

    Increase the suspend count (so you don't actually resume the thread if it drops to 0) in KTHREAD.SuspendCount.

    Call NtAlertResumeThread and see what happens.

    Check that the SuspendCount is reduced back to the original after you call NtAlertResumeThread.
    Hopefully when the original ResumeThread is called, the fact that the LdrpInitializeProcess APC has already been run won't matter to the process starting normally. In the meantime, you've had the opportunity to do whatever it is you want to do re the Olly attach.


    btw, your [fs:18h + 0F24h] is probably TEB.DbgSsReserved and is part of the DbgUiConnectToDbg function. Do a "dt _TEB" in WinDbg/LiveKd to check the offset for your OS.


    Kayaker

  9. #9

    It seems idea is great.
    I gonna try it and see what happens...
    I should look out my posts,Or JMI will get mad at me! ;)

  10. #10
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,048
    Blog Entries
    5
    Just thinking you could get the thread handle from NtOpenThread and using the value from ETHREAD.Cid.(UniqueThread) as the required parameter for that API.

    As you're probably aware, the EPROCESS and ETHREAD offsets vary with the OS version. There are ways to get offset-independant references to certain of these fields, which you'd of course want for a plugin.

    You may already be aware of the "classic" rootkit way of finding the offset of EProcess->ImageFileName by calling the following function from DriverEntry:

    Code:
    /***********************************************************
    
    				GetOffsetOfProcessName
    
      Find offset of EProcess->ImageFileName, irrespective of OS version
      (Hoglund/Russinovich)  
    
      When called from DriverEntry we are in the System context,
      so we simply search the current EPROCESS structure 
      for the process string "system"
    
    ***********************************************************/  
    
    ULONG GetOffsetOfProcessName()
    {
    
      ULONG			ul_offset;
      PEPROCESS		CurrentEProcess;
    
      ////////////////////////////////////////////////////
    
       CurrentEProcess = PsGetCurrentProcess();
          
    	// EPROCESS considered no larger than a page size.
    
       for(ul_offset = 0; ul_offset < PAGE_SIZE; ul_offset++)
    
       {
          if( !strncmp( "System", (PCHAR) CurrentEProcess + ul_offset,
                        strlen("System")))
          {
    		  return ul_offset;
          }
       }
    
       return 0;
    
    }
    
    /***********************************************************/

    I've developed several more based on this idea of finding the absolute offset of selected fields in a known way. Here are 2 examples that might be pertinent here, and are simply run as an IOCTL from your own driver (context of your own process) and the offsets saved for future reference. I've got several others as well.

    To increment KTHREAD.SuspendCount (if you find you need to do that), you might be able to call SuspendThread, incrementing the suspend count (to MAXIMUM_SUSPEND_COUNT).


    Code:
    // Called from IOCTL
    
    ////////////////////////////////////////////////////
    // Get the absolute offset of various ETHREAD structre
    // entries, regardless of OS version
    ////////////////////////////////////////////////////
    	
    offsetETHREAD_Cid = GetOffsetOfCid();
    offsetETHREAD_ThreadListEntry = GetOffsetOfThreadListEntry();

    Code:
    		 
    /***********************************************************
    
    			GetOffsetOfCid
    
    	Obtain offset of EThread->Cid
    
    	  http://computer.forensikblog.de/
    
    		_ETHREAD version 5.0.2195.7045 Microsoft Windows 2000.
    		  +0x1e0 Cid       : struct _CLIENT_ID
    			  +0x000 UniqueProcess
    			  +0x004 UniqueThread
    
    		_ETHREAD Version 5.1.2600.0 Windows XP. 
    		  +0x1ec Cid       : struct _CLIENT_ID
    
    		_ETHREAD Version 5.2.3790.0 Microsoft Windows Server 2003
    		  +0x1f4 Cid       : struct _CLIENT_ID
    
    ***********************************************************/  
    
    ULONG GetOffsetOfCid()
    {	
    	
      ULONG				ul_offset;
      ULONG				CurrentProcessId;
      PETHREAD			CurrentEThread;	
    
    
      ////////////////////////////////////////////////////
    
    	CurrentProcessId = (ULONG)PsGetCurrentProcessId();
    	CurrentEThread = PsGetCurrentThread();
    
    	// ETHREAD considered no larger than a page size.
    
    	for(ul_offset = 0; ul_offset < PAGE_SIZE; ul_offset++)
    	{
    		if( *(ULONG*) ( (BYTE*)CurrentEThread + ul_offset) == CurrentProcessId )
    		{
    			// found _CLIENT_ID.UniqueProcess
    			return ul_offset;
    		}
    	}
    
    	return 0;
    	
    }
    
    /***********************************************************/
    Code:
    /***********************************************************
    
    			GetOffsetOfThreadListEntry
    
    	Obtain offset of EThread->ThreadListEntry
    
    	 EPROCESS.ThreadListHead is a linked list pointer to
    	 ETHREAD.ThreadListEntry
    
    	 EPROCESS +0x050 ThreadListHead   : struct _LIST_ENTRY
    				+0x000 Flink
    				+0x004 Blink
    	
    	  http://computer.forensikblog.de/
    
    		_ETHREAD version 5.0.2195.7045 Microsoft Windows 2000.
    		+0x1a4 ThreadListEntry  : struct _LIST_ENTRY
    
    		_ETHREAD Version 5.1.2600.0 Windows XP. 
    		+0x1b0 ThreadListEntry  : struct _LIST_ENTRY
    
    		_ETHREAD Version 5.2.3790.0 Microsoft Windows Server 2003
    		+0x1ac ThreadListEntry  : struct _LIST_ENTRY
     
    ***********************************************************/  
    
    ULONG GetOffsetOfThreadListEntry()
    {	
    	
      PEPROCESS		CurrentEProcess;
      PETHREAD		CurrentEThread;	  
      ULONG			pThreadListEntry;
    
      ////////////////////////////////////////////////////
    
    	CurrentEProcess = PsGetCurrentProcess();
    	CurrentEThread = PsGetCurrentThread();
    
    	pThreadListEntry = (( (unsigned long)
    				CurrentEProcess->Pcb.ThreadListHead.Flink
    				));
    			
    	// Obtain the relative offset of ETHREAD.ThreadListEntry by
    	// subtracting it with the *known* ETHREAD structure starting offset
    
    	return (ULONG)((BYTE*)pThreadListEntry - (BYTE*)CurrentEThread);			
    
    }
    
    /***********************************************************/

    btw, there's no need to quote the entire post when replying to a post if it's obvious what you're replying to.

    Kayaker

  11. #11
    hi Kayaker
    Calling SuspendThread on a already suspended thread do something more than increasing suspend count of thread?
    Because I thought it will be more easier to call SuspendThread on my suspended process in order to increase suspend count rather than manually change values in EPROCESS and ETHREAD, then call NtAlertResumeThread.
    But this way is not working or it seems NtAlertResumeThread will alert APC before resuming thread IF decreased suspend count reachs 0, so if we manually increase suspend count NtAlertResumeThread will not alert APC,because suspend count is more than 0.
    Am I wrong somewhere?or there is difference between manually change values in EPROCESS and calling SuspendThread?

    Edit:
    I suddenly thought a strange idea. Is it possible to force LdrpInitializeProcess for that suspended process?
    I mean inject a code in order to use our suspended thread PEB rather than current thread one in here:
    Code:
    :7C921ABC _LdrpInitializeProcess@20 proc near     ; CODE XREF: _LdrpInitialize(x,x,x)+88CE
    ...
    :7C921B36                 mov     eax, large fs:18h ; TEB
    :7C921B3C                 mov     ebx, [eax+30h]  ; PEB <-in here
    Do you think will it be able to intialize PEB_LDR_DATA correctly for our suspended thread?

    Regards
    Last edited by Hero; March 7th, 2009 at 02:27.
    I should look out my posts,Or JMI will get mad at me! ;)

  12. #12
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,048
    Blog Entries
    5
    I dunno. I thought that NtAlertResumeThread might allow the outstanding APC (which will execute LdrpInitializeProcess) to execute. I'm not even sure if that APC has been created/queued yet at that point. There are some ETHREAD fields you could check that might tell you the APC status. If there is an outstanding one, then it's probably the LdrpInit one.

    If NtAlertResumeThread won't trigger the APC to run, perhaps you can force the thread into an alertable state, without actually resuming it, with SleepEx (which, like the Wait functions are supposed to accomplish that):

    http://msdn.microsoft.com/en-us/library/aa363772(VS.85).aspx

    Again this is all guesswork because I don't know what you can force onto an already suspended thread (especially one which hasn't even begun to execute or been fully initialized).

  13. #13
    Hi Kayaker
    Rather than using those APIs,I found an undocumented API called NtAlertThread that should send thread in alerted state(or at least I think like that...),so APCs should run now.
    But nothing happened again,then I think the APCs are not even created when we create process in suspended mode.
    So I though for other ways. What do you think is better:
    1-Try to find a way to load modules without resuming process.
    2-A funny way but I donna if it works always or not: create another instance of process in debug mode,patch a "int 3" at its OEP, and when you stop at that "int 3",get its module list...
    3-find out how TLS works... how TLS routines can call API function? TLS routines run even though you create process as suspended,then how they can call APIs whithout having modules loaded?or I'm wrong and modules are loaded in suspended mode,but PEB_LDR_DATA has not filled yet?

    Regards
    I should look out my posts,Or JMI will get mad at me! ;)

Similar Threads

  1. IDA: Attach to Process -> Menu deactivated
    By Drigo in forum Tools of Our Trade (TOT) Messageboard
    Replies: 1
    Last Post: May 14th, 2009, 00:31
  2. Extended Precision representation
    By r3aper in forum The Newbie Forum
    Replies: 2
    Last Post: March 19th, 2009, 00:03
  3. Attach to process WITHOUT stopping
    By w00b in forum OllyDbg Support Forums
    Replies: 6
    Last Post: February 2nd, 2008, 11:38
  4. Unable to Attach to Process
    By Anonymous in forum OllyDbg Support Forums
    Replies: 11
    Last Post: October 1st, 2003, 19:33
  5. Attach
    By Anonymous in forum OllyDbg Support Forums
    Replies: 6
    Last Post: February 19th, 2003, 16:24

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •