beating IsDebuggerPresent for my unpacker

[Shub-Nigurrath]

absolutely correct, there are plenty ways to inject code into another one, directly in memory..

see the well known paper, just to start on this argument..

http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767

[upb]

bool DisableBeingDebuggedFlag(HANDLE thread)
{
	CONTEXT ctx;

	ctx.ContextFlags = CONTEXT_SEGMENTS;
	if (!GetThreadContext(thread, &ctx))
	{
		error(FF "GetThreadContext(0x%08X)", FL, thread);
		return false;
	}

	LDT_ENTRY sel;
	if (!GetThreadSelectorEntry(thread, ctx.SegFs, &sel))
	{
		error(FF "GetThreadSelectorEntry(0x%08X)", FL, thread);
		return false;
	}

	DWORD fsbase = (sel.HighWord.Bytes.BaseHi << 8| sel.HighWord.Bytes.BaseMid) << 16 | sel.BaseLow;
	DWORD RVApeb;
	SIZE_T numread;

	if (!ReadProcessMemory(hproc, (LPCVOID)(fsbase + 0x30), &RVApeb, 4, &numread) || numread != 4)
	{
		error(FF "ReadProcessMemory(0x%08X, 0x%08X, 0x%08X, ...)", FL,
			hproc, (fsbase + 0x30), &RVApeb);
		return false;
	}

	WORD beingDebugged;
	if (!ReadProcessMemory(hproc, (LPCVOID)(RVApeb + 2), &beingDebugged, 2, &numread) || numread != 2)
	{
		error(FF "ReadProcessMemory(0x%08X, 0x%08X, 0x%08X, ...)", FL,
			hproc, RVApeb, &beingDebugged);
		return false;
	}

	beingDebugged = 0;

	if (!WriteProcessMemory(hproc, (LPVOID)(RVApeb + 2), &beingDebugged, 2, &numread) || numread != 2)
	{
		error(FF "ReadProcessMemory(0x%08X, 0x%08X, 0x%08X, ...)", FL,
			hproc, RVApeb, &beingDebugged);
		return false;
	}

	return true;
}

btw.... Shub-Nigurrath, is this needed for speed optimization or what ?:PPP

__asm
{
add addrIDP, 9
}

[dyn!o]

Looks nice (logic). Anyway, won't work on 9x family.

Now, all hardcore maniacs, tell me why?

Regards.

[upb]

give me a kernel32.dll from 9x and i'll answer you hehe
(i dont have any laying around here and dont have any docs about win9x TIB, PEB(?!?) either).

[dyn!o]

Hey, that would be too easy

You are accessing segment register to obtain the address of PEB and read process data. Since TEB (or TIB if you like) and PEB are well settled on WinNT clones but not on Win9x family, you have to be familiar with Win9x/WinNT kernels.

TEB is not a problem here because its field is the same on all Windows. The problematic topic in your example is PEB.

By using two additional APIs you will be able to add Win9x compatibility to the method you presented.

I made my homework. Who's next (to tell us which APIs I'm talking about or/and present another solution)?

Regards.

upb you want 9x IsDebuggerPresent raw code in kernel32.dll ??

her it is if you wanted that

BFF946F6 IsDebuggerPresent    A1 E49CFCBF      MOV EAX,DWORD PTR DS:[BFFC9CE4]
BFF946FB                      8B08             MOV ECX,DWORD PTR DS:[EAX]
BFF946FD                      8379 54 01       CMP DWORD PTR DS:[ECX+54],1
BFF94701                      1BC0             SBB EAX,EAX
BFF94703                      40               INC EAX
BFF94704                      C3               RETN

well on being single stepped through

DS:[BFFC9CE4]=C00309C8
EAX=00401000 (OLLYDBG.<ModuleEntryPoint>)

second instruction

DS:[C00309C8]=81752074
ECX=81752094

817520B4  3C 21 75 81 B0 A0 5F C1 80 0B 75 81 80 26 75 81  <!u���_��u��&u�
817520C4  BC 47 74 81 0C D0 5B 83 00 00 00 00 00 00 00 00  �Gt�.�[�........

flag position on compare

EAX C00309C8
ECX 81752074
EDX 817520D4
EBX 00680000
ESP 0078FE38
EBP 0078FF78
ESI 81752074
EDI 00000000
EIP BFF946FD KERNEL32.BFF946FD
C 0  ES 016F 32bit 0(97A0)
P 1  CS 0167 32bit 0(FFFFFFFF)
A 0  SS 016F 32bit 0(97A0)
Z 0  DS 016F 32bit 0(97A0)
S 1  FS 3517 16bit 81752270(37)
T 0  GS 0000 NULL
D 0
O 1  LastErr ERROR_INVALID_NAME (0000007B)
EFL 00200A86 (O,NB,NE,A,S,PE,GE,G)

flag position after compare

EAX C00309C8
ECX 81752074
EDX 817520D4
EBX 00680000
ESP 0078FE38
EBP 0078FF78
ESI 81752074
EDI 00000000
EIP BFF94701 KERNEL32.BFF94701
C 0  ES 016F 32bit 0(97A0)
P 0  CS 0167 32bit 0(FFFFFFFF)
A 0  SS 016F 32bit 0(97A0)
Z 0  DS 016F 32bit 0(97A0)
S 1  FS 3517 16bit 81752270(37)
T 0  GS 0000 NULL
D 0
O 0  LastErr ERROR_INVALID_NAME (0000007B)
EFL 00200282 (NO,NB,NE,A,S,PO,L,LE)

on return

Return to 00401005 (OLLYDBG.00401005)

registers and flag on return 
EAX 00000001
ECX 81752074
EDX 817520D4
EBX 00680000
ESP 0078FE38
EBP 0078FF78
ESI 81752074
EDI 00000000
EIP BFF94704 KERNEL32.BFF94704
C 0  ES 016F 32bit 0(97A0)
P 0  CS 0167 32bit 0(FFFFFFFF)
A 0  SS 016F 32bit 0(97A0)
Z 0  DS 016F 32bit 0(97A0)
S 0  FS 3517 16bit 81752270(37)
T 0  GS 0000 NULL
D 0
O 0  LastErr ERROR_INVALID_NAME (0000007B)
EFL 00200202 (NO,NB,NE,A,NS,PO,GE,G)

now ollydbg cant see the address 0xc00309c8

[upb]

i started reading the MSJ may 1996 article and found another thing that can be used to check for a debugger in win9x:

Windows 95 TIB fields
The 20h DWORD DebugContext field normally contains the value zero. However, when you're debugging the thread's process, this field contains a pointer to a structure that contains register values and is similar to, but not the same as, the CONTEXT structure defined in WINNT.H.

however, reading JuneMouse's (thx) post, kernel code is clearly checking something else, dereferencing a pointer in kernel32.dll memory? seems that this pointer points into kernel (so called 'kernel' memory under win9x hehe, >= 0x80000000) memory.

Dno, after researching for 30 mins, i dont have enough motivation to add support for this ancient architecture :P
anyone who does, read this article: hxxp://www.microsoft.com/msj/archive/S2CE.aspx

The 30h PVOID* pProcess field contains a linear address for the process database representing the process that owns the thread. However, this is not the same as a process handle or process ID.

however,there is no info on the PDB format there...