[kmd]

I noticed however that you mention not having access to writing to the target's address space (NtWriteVirtualMemory), how do you expect to execute custom APC code within that process then?

He will locate some string in memory (for example ernel32.dll, ser32.dll), place a special dll somewhere on search paths and execute APC with LoadLibraryXXX call and this address as parameter. This is very old trick.

yes this is my way.
unfortunately NtQuerySystemInformation not solves my task. it is impossible to filter alertable threads with only THREAD_STATE struct or i dunno how :(

[kmd]

up!

still nobody has any ideas?

[EP_X0FF]

up!

still nobody has any ideas?

Probably there is no 100% functional and compatible way to do what you want. This KTHREAD flag is not exported or mentioned in any API's that gathering info about thread by user mode request.
Available options:

1. Force thread to alertable state: inject + any API that forces thread into alertable state
2. Read kernel memory through NtSystemDebugControl, or PhysicalMemory section (only for anything lower than 3790 SP1): locate ethread object -> NtQuerySystemInformation(info class handles), read structure, locate pointer to flags, read it. Difficult to develop and not scalable.
3. Use KdSystemDebugControl (it is NtSystemDebugControl functionality built for WinDBG for using in Vista+). This method has a critical count of disadvantages due to amount of requirements. You need system set in debug mode, debug privilege, kd driver handle, IOCTL code.
4. Investigate call stack of the specified thread you want to analyze for specific calls, or analyze thread start address for TppWorkerThread for example (Vista+, unexported afair). Play with windbg !process command.
5. Write a small driver to extract this flag. Thread structure however is opaque and subject of constant changes between Windows version.
6. Revise what you want to do and how you want to do this. Probably this is the best option.

[kmd]

thanx thread can be closed.