Winject 1.7b

[mcMike]

Greetings,

Minor update of Winject.

I keep latest tested build here without too much announcing the updates anymore. Screenshots (in wrong order though):

1) Winject is now able to reset DebugPort to allow debugger attaching to already debugged process.
There is slight incompatibility problem though. Patching only works with XP and SP2 "preinstalled" - not postinstalled. I am working on that next.

[Sparten]

file approved, once again, Great job

[[XEF]Leg@liz]

It is compatible with "pbuster.dll" and MultiHack for BF2 demo ?

[scruie]

its been discussed in a few threads in BF2; this one springs to mind:
http://www.mpcforum.com/showthread.php?t=97287

there is more but i'm too lazy to find them - search is wonderful when i can be bothered

[VoN DuTch™]

Uploaded::

Filename: Winject 1.4.rar
Database: MPCDownloads.com -> BF1942

----

[LkCuMeSnap]

Originally Posted by [XEF]Leg@liz

It is compatible with "pbuster.dll" and MultiHack for BF2 demo ?

Try that one. But remember: it can only defeat detection by common md5
checks. It's not a generic bypass for hacks that are detected by method
like memory corruption, Invalid O/S privileges, game hack (detour), ...

BTW

I'm working on a generic kernel mode hook to create an Olly plugin
versus "_eprocess->debuggerport already set". If anybody wants
to join I could need some helping hand.

The plugin will also bypass the usual anti debug tricks like the shit
evilBalance uses in its clients.

[Diddle]

File:		pbuster.zip
Status:		OK
MD5:		38534db1142d81ad19f65c9c5b0959c7
Packers Detected: -

Scanner Results
AntiVir:		Found Nothing
ArcaVir:		Found Nothing
Avast:			Found Nothing
AVG Antivirus:		Found Nothing
BitDefender:		Found Nothing
ClamAV:			Found Nothing
Dr. Web:		Found Nothing
F-Prot Antivirus:	Found Nothing
Fortinet:		Found Nothing
Kaspersky Anti-Virus:	Found Nothing
NOD32:			Found Nothing
Norman Virus Control:	Found Nothing
UNA:			Found Nothing
VBA32:			Found Nothing

Source: Jotti's Virusscan

File is Clean --> Approved.

[mcMike]

Originally Posted by LkCuMeSnap

I'm working on a generic kernel mode hook to create an Olly plugin versus "_eprocess->debuggerport already set". If anybody wants
to join I could need some helping hand.

The plugin will also bypass the usual anti debug tricks like the shit
evilBalance uses in its clients.

Hello,
Do you mean a _real_ ring0-mode stuff aka SSDT hooking or Kernel32.dll hook?

For PEB/_EPROCESS I would suggest semi-undocumented NtQueryInformationProcess() and NtSetInformationProcess().
I already managed to read _EPROCESS->DebugPort and base of PEB and check 3rd BOOL from there for PEB->BeingDebugged.

Now I go work with resetting those....


ps. That new DLL seems to work with winject->bf2.exe

[VoN DuTch™]

--Approved (Winject 1.5b.rar)

Uploaded::

Filename: Winject 1.5b.rar
Database: MPCDownloads.com -> BF1942

----

[h4x0rz4lyfe]

Awesome work Mike. I have a quick question. If I were yo use WinInject with BF2 and n7bf2 0.3 and ge tthem all to work together could PB hardware ban me. I know since the last update noone has been caught doing this. Can PB catch you doing this without updating?

[Spontaneous]

h4x0rz4lyfe, depends on how they want to detect it. Some ways they can detect new things without updating, IF they have a way that is compatible to detect it. If they have to use a new detection method, then they would have to update. So it all depends on if the detection methods built into PB currently can detect it or not.

[LkCuMeSnap]

v1.5 b fixed the bug at the kernel hook check I mentioned.
Well done mike. Check advanced coding for the Pb bypass.

[mcMike]

Originally Posted by LkCuMeSnap

v1.5 b fixed the bug at the kernel hook check I mentioned.
Well done mike. Check advanced coding for the Pb bypass.

thx. I did look but didn't see anyting new. Well new PBuster.dll but how about that description...?
I am working my ass of for brute-method with slow but constant success though.

[VoN DuTch™]

--Approved (Winject15c(exeonly).rar)

Uploaded::

Filename: Winject 1.5c (exe).rar
Database: MPCDownloads.com -> BF1942

----

[mcMike]

Uploaded 1.6 in begin of thread.

There is some incompatibility problem in SP2 preinstalled and post installed.
The winject DebugPort patching works only with preinstalled. The problem seems to be with ZwQuerySystemInformation().

In SP1 and post SP2 installs it don't seem to find any matching ProcessID=ParendPID OR not matching child process object with target processID. I cannot pinpoint which one fails yet. The _EPROCESS offsets seems to be same though (0x84 for UniquePID).

Any ideas what gives? BfLover?

// get real buffer length
NTSTATUS status = ::ZwQuerySystemInformation( SystemHandleInformation, &dummy, sizeof(dummy), &uReturn );

// ignore status, should be length mismatch
PVOID buf = ::LocalAlloc( LMEM_FIXED, uReturn);

if(buf)
{
  status = ::ZwQuerySystemInformation( SystemHandleInformation, buf, uReturn, &uReturn);
  
  if( status == 0) 
  {
  PSYSTEM_HANDLE_INFORMATION pSysHandle = ( PSYSTEM_HANDLE_INFORMATION )(buf);

  for( int ui = 0; ui < pSysHandle->NumberOfHandles; ui++ )
  {
	// Look for CSRSS.exe PID (=ParentPID)
	if( (pSysHandle->Handles[ui].ProcessId == parentPID) && (pSysHandle->Handles[ui].ObjectTypeNumber == 5))
	{	
		dwEProcessBase = (DWORD)(pSysHandle->Handles[ui].Object);		// Read Base of Eprocess for this Process-object
	
		// Transfer to Physical Address
		dwEBasePhys=(DWORD)GetPhysicalAddress(dwEProcessBase);			
		
		// Read this child Processes PID from EPROCESS->UniquePID
		handlePID=ReadPhysMem(dwEBasePhys,nSize,(dwEProcessBase & 0x00000fff) + EPoffSet_PID); // 0x84
								
		// Look for target pID 
		if (handlePID==PID)			
		{
			::LocalFree( buf);
			return dwEProcessBase;	// Return Childs _EPROCESS address
		}

		handlePID=0; // Reset for for next loop
	}
  }
}

::LocalFree( buf);

return 0;
}