Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

Attach Extended

Plugin related discussions.

For plugins, tools and tutorials see <a href="/collaborative/tools/index.php/Category:OllyDbg_Extensions">OllyStuph</a>
Locked
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Attach Extended

Post by Hero »

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
Attachments
AttachExtended.rar
(6.02 KiB) Downloaded 385 times
I should look out my posts,Or JMI will get mad at me! ;)
User avatar
arc_
Member
Posts: 90
Joined: Tue May 13, 2008 2:24 am

Post by arc_ »

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.
User avatar
dELTA
Posts: 4209
Joined: Mon Oct 30, 2000 7:00 am
Location: Ring -1

Post by dELTA »

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."
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

arc_ wrote: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.
dELTA wrote: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
I should look out my posts,Or JMI will get mad at me! ;)
User avatar
dELTA
Posts: 4209
Joined: Mon Oct 30, 2000 7:00 am
Location: Ring -1

Post by dELTA »

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. :yay:

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/t ... chExtended
"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."
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

dELTA wrote: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. :yay:

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/t ... chExtended

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: Select all

.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
I should look out my posts,Or JMI will get mad at me! ;)
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

OK,now I need to get some help.... :p

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. :p

Regards
I should look out my posts,Or JMI will get mad at me! ;)
User avatar
Kayaker
Posts: 4179
Joined: Thu Oct 26, 2000 11:00 am

Post by Kayaker »

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.

showthread.php?t=11154


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

http://undocumented.ntinternals.net/Use ... hread.html

Code: Select all

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.


[B]Difference between AlertResumeThread and ResumeThread[/B]:
the first one sets Thread Object to alerted state 
(so before thread will continue execution, [b]all APC will be executed[/b]).

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. :D

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
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

:yay:
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! ;)
User avatar
Kayaker
Posts: 4179
Joined: Thu Oct 26, 2000 11:00 am

Post by Kayaker »

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: Select all

/***********************************************************

				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: Select all

// Called from IOCTL

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

Code: Select all

		 
/***********************************************************

			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: Select all

/***********************************************************

			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
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

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: Select all

:7C921ABC [email protected] 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
I should look out my posts,Or JMI will get mad at me! ;)
User avatar
Kayaker
Posts: 4179
Joined: Thu Oct 26, 2000 11:00 am

Post by Kayaker »

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 ... S.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).
Hero
Senior Member
Posts: 226
Joined: Sun Jun 13, 2004 7:00 am

Post by Hero »

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... :p ),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... :speechless:
3-find out how TLS works... :p 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! ;)
Locked