Is there a way to find a process ID by file name? It appears that in the GDT there are only 4 valid TSS's at all times. So when we open a new program there is no new TSS assigned to the program but we actually run in one of Windows own tasks. Selector 05 is always marked busy and is the only TSS large enough to have a IO permission bit map and interrupt redirection table. In fact Ke386QueryIoAccessMap gives a pointer to an are of memory way out toward end of memory and Ke386SetIoAccessMap copies what ever changes have been made back to this particular TSS at offset 88h.

00000000 00 00 00 00 00 00 00 00-FF FF 00 00 00 9B CF 00 ................
00000010 FF FF 00 00 00 93 FF 00-FF FF 00 00 00 FB CF 00 ................
00000020 FF FF 00 00 00 F3 CF 00-AB 20 00 80 24 8B 00 80 ......... ..$...

The TSS is static and the address is 80248000h with a limit of 20ABh.

I want to get the process ID of a particuliar user mode process and assign it the rights to I/O instructions.
Posted on 2003-12-24 00:23:23 by mrgone
well an executable file can have multiple process IDs if there are multiple instances of it. List all running processes with EnumProcesses and compare each prcesseses filename with the target file name.

EDIT
turns out EnumProcesses dosen't provide filenames in the way the win9x functions do.
Posted on 2003-12-24 00:30:24 by ENF
You do a snap module and get the module name from the MODULEENTRY32 structure. Ths should get you started :

SearchForProcess proc pFindName:DWORD

LOCAL pe32 :PROCESSENTRY32
LOCAL me32 :MODULEENTRY32
LOCAL hProcessSnap :HANDLE
LOCAL hModuleSnap :HANDLE
LOCAL result :DWORD

mov result,NULL

mov pe32.dwSize,SIZEOF PROCESSENTRY32
mov me32.dwSize,SIZEOF MODULEENTRY32

invoke CreateToolhelp32Snapshot,TH32CS_SNAPPROCESS,0
.IF eax == -1
ret
.ENDIF
mov hProcessSnap,eax
invoke Process32First,hProcessSnap,ADDR pe32
.IF eax==0
ret
.ENDIF

.WHILE eax
invoke CreateToolhelp32Snapshot,TH32CS_SNAPMODULE,pe32.th32ProcessID
mov hModuleSnap,eax
invoke Module32First,hModuleSnap,ADDR me32
invoke CloseHandle,hModuleSnap
[color=red]; The file name is in me32.szExePath[/color]
invoke lstrcmpi,pFindName,ADDR me32.szExePath
.IF !eax
[color=red]; The Process ID is in pe32.th32ProcessID[/color]
mov eax,pe32.th32ProcessID
mov result,eax
.BREAK
.ENDIF
invoke Process32Next,hProcessSnap,ADDR pe32
.ENDW
invoke CloseHandle,hProcessSnap

mov eax,result
ret
SearchForProcess endp
Posted on 2003-12-24 00:45:53 by donkey
had no idea CreateToolhelp32Snapshot exited on nt thought it was 9x only.
Posted on 2003-12-24 00:51:14 by ENF
It is available on Win2K, XP and Server 2003. It is not available on NT4 however. I generally just ignore NT4 so that is never a big problem for me. I have an adapted routine for NT4/everything else but it is a bit longer.
Posted on 2003-12-24 00:57:11 by donkey
I'm kinda confused because I have W2k prof. and XP and the "Professional" says it's NT version 5.0. So where do I stand in the NT 4.0 border?
Posted on 2003-12-24 01:09:24 by mrgone
Everything above WinNT4 has the wrappers for ToolHelp so Win2K and XP any version are fine. NT4 was the last in the "true" NT family, since then NT5 has been a hybrid of Win9x/NT, they were given the names 2K and XP but they are really NT5. I'll have to find the older NT4 included version on my archives, I will take a look around.
Posted on 2003-12-24 01:11:46 by donkey
Below is the TSS I refered to in first post. The size or limit is 20ABh. Offset 66h is the pointer to the I/O permition bit map. It's address is relative to TSS base address. Notice it points just the other side or one byte past end of TSS. Well after struggling with functions to decrement KPROCESS pointer I thought I would test this first. I tried setting the pointer to 88h which is where the bitmap actually starts. After leaving the driver, Windows sets it right back...lol. I wasn't sure so I wrote that 0088h you see at offset 20h. It stayed...lol.

00000000 00 00 00 00 E0 3D C1 BE-10 00 00 00 00 00 00 00 .....=..........
00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 03 00 ................
00000020 88 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 AC 20-04 00 00 18 18 00 00 00 ....... ........
00000070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00-FF FF FF FF FF FF FF FF ................
00000090 FF FF FF FF FF FF FC FF-FF FF FF FF FF FF FF FF ................
Posted on 2003-12-25 00:09:29 by mrgone
Donkey, NT5+ are still *true* NTs - they just added support for directx and other features 9x had... calling NT5+ NT/9x hybrids is pretty wrong, considering how the kernel and the rest of the system works...
Posted on 2003-12-25 05:22:05 by f0dder