Reverse Engineering Citrix ThinWire

CARE: Crash Analysis Report Environment

DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.

Twitter @ DumpAnalysis
You can now follow portal and blog news at DumpAnalysis on Twitter

LinkedIn Group Dr. Watson Enthusiasts
All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)

2010 (0x7DA) - The Year of Dump Analysis
2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade

Crash dumps (and live debugging) can be very useful for reverse engineering component dependencies. Let’s look at MS Video Driver Architecture UML component diagram (synthesized after reading various articles from OSR and DDK):

Coupled with this understanding and armed with Citrix symbol files (which are freely downloadable from Citrix support and you don’t really need them to see component dependencies) I was able to transform this thread stack below and other similar stacks into the following UML component diagram (some functions are shown as module!xxx and offsets are removed for clarity):

nt!KiSwapContext
nt!KiSwapThread
nt!KeWaitForSingleObject
tcpip!xxx
tcpip!TCPDispatch
nt!IofCallDriver
nt!xxx
nt!xxx
TDTCP!xxx
TDTCP!xxx
TDTCP!TdIoctl
termdd!_IcaCallSd
termdd!IcaCallNextDriver

pdrframe!xxx
pdrframe!PdIoctl

termdd!_IcaCallSd
termdd!IcaCallNextDriver

pdcrypt1!xxx
pdcrypt1!PdIoctl

termdd!_IcaCallSd
termdd!IcaCallNextDriver

WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!WdIoctl

termdd!IcaCallStack
termdd!IcaCallDriver
termdd!IcaDeviceControlChannel
termdd!IcaDeviceControl
termdd!IcaDispatch

win32k!GreDeviceIoControl
win32k!EngDeviceIoControl

vdtw30!xxx
vdtw30!xxx

win32k!vMovePointer
win32k!GreMovePointer
win32k!xxxMoveEventAbsolute
win32k!ProcessMouseInput
win32k!InputApc

nt!KiDeliverApc
nt!KiSwapThread
nt!KeWaitForMultipleObjects
win32k!xxxMsgWaitForMultipleObjects
win32k!xxxDesktopThread
win32k!xxxCreateSystemThreads
win32k!NtUserCallOneParam

nt!KiSystemServiceCopyEnd
nt!KiSwapThread
nt!KeWaitForSingleObject
win32k!EngWaitForSingleObject
vdtw30!xxx
vdtw30!xxx
vdtw30!xxx
vdtw30!DrvTw2SaveScreenBits

win32k!GreSaveScreenBits
win32k!CreateSpb
win32k!zzzChangeStates
win32k!zzzBltValidBits
win32k!xxxEndDeferWindowPosEx
win32k!xxxSetWindowPos
win32k!xxxShowWindow
win32k!NtUserShowWindow

nt!KiSystemService
USER32!NtUserShowWindow
USER32!InternalDialogBox
USER32!DialogBoxIndirectParamAorW
USER32!DialogBoxParamW

We replace MS components with Citrix ones:

  • Video Display with vdtw30.dll
  • Video Miniport with icacdd.sys
  • Hardware and HAL with Terminal Services stack components (MS termdd.sys, Citrix wdica.sys, etc)

twarchitecture.JPG

- Dmitry Vostokov -

           

Announcements

Coming Soon:

Debugging Notebook: Essential Concepts, WinDbg Commands and Tools

Crash Dump Analysis for System Administrators and Support Engineers

New Magazines:

Debugged! MZ/PE: MagaZine for/from Practicing Engineers


New Books:

Memory Dump Analysis Anthology, Volume 3

First Fault Software Problem Solving: A Guide for Engineers, Managers and Users

x64 Windows Debugging: Practical Foundations

Also available:

Windows Debugging: Practical Foundations

DLL List Landscape: The Art from Computer Memory Space

Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov

WinDbg: A Reference Poster and Learning Cards

Memory Dump Analysis Anthology, Volume 2

Memory Dump Analysis Anthology, Volume 1

New Children's Book:

Baby Turing

6 Responses to “Reverse Engineering Citrix ThinWire”

  1. Toby Opferman Says:

    The diagram is slightly inaccurate. The video driver only ever directly links against WIN32K and would not call VideoPort.Sys directly without going through WIN32K. There is also another Citrix related path missing which I would not be able to mention in a public forum.

  2. Dmitry Vostokov Says:

    Thanks for pointing this out! This was adopted from the picture in OSR article:

    From Andy’s Bookshelf: So you Wanna Write a Video Driver?
    Figure 2 - DDI and Miniport Drivers

    http://www.osronline.com/article.cfm?id=66

    I’ll add a label to that link: “via win32k!EngDeviceIoControl” similar I’ve done for vdtw30.dll and termdd.sys interaction

    Thanks,
    Dmitry

  3. Toby Opferman Says:

    No problem. The video display driver also directly accesses the hardware and performs things such as DMA transfers. This helps speed things up as it then doesn’t require the display driver to send an IRP to the miniport for every graphic command.

    http://www.codeproject.com/system/driverdev6asp.asp

  4. Dmitry Vostokov Says:

    Corrected both diagrams (removed direct link from video display driver to video port driver)

    Thanks,
    Dmitry

  5. Software Generalist » Blog Archive » Reading Notebook: 24-July-09 Says:

    […] USER and GDI functions (pp. 54 - 55) - Long time ago I created a UML component diagram depicting component dependencies extracted from stack traces: http://www.dumpanalysis.org/blog/index.php/2006/10/24/reverse-engineering-citrix-thinwire/  […]

  6. Software Generalist » Blog Archive » Reading Notebook: 16-July-09 Says:

    […] Terminal services (pp. 19 -20) - an for architectural overview (UML diagram) please see this post: Reverse Engineering Citrix ThinWire  […]

Leave a Reply