UPDD V6 refers to the driver package version. Components of the package have their own independent versions such as the various libraries used by the driver. The actual core driver is Version 6. UPDD components used to post touch data into the OS are signed components utilised from UPDD V5, hence are listed as V5 components in the Device Manager. However, all these components, when packaged together, form the basis of the UPDD version 6 driver.

The driver is configured in a Windows system as follows:

This system configuration may have slight variations depending on the version of Windows in use. The example images below are taken from a Win 10 system.

Driver

The driver, updd.sys, runs as a user mode system service.

The driver uses TCP/IP port 4146 to communicate between components using the API.

Kernel Modules

The kernel mouse and HID interface modules are loaded due to the addition of relevant register entries in the system Registry.

Client Applications

The client applications are added to the Windows run list in the system registry to be invoked at startup:

UPDD Commander replaces UPDD Gestures and UPDD TUIO functionality from previous releases:

Start / stopping the driver processes

Should you need to stop / start the driver, say to activate a setting update that is only activated at driver load, you can of course reboot the system or alternatively the above Services dialog can be used to start and stop the driver as can the commands 'net stop updd' and 'net start updd'.

The commands must be run in a command window with administrator privileges:

To stop / start the driver's background process

or locate the process in the Task Manager and select end task

To start the process double click the program in Explorer in the UPDD Application folder:

To start / stop UPDD commander

To stop Commander, select "Quit UPDD Commander" from the Commander system tray entry.

To start Commander, locate Commander in Explorer in the UPDD applications folder and double click the UPDD Commander entry.

Registry entries

The following main entries are created by the driver (others may be created by Windows as a result of installing a driver):

Entry	Description
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Touch-Base Ltd	Driver path and version
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\updd	Driver entries
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\upddvh	Virtual HID usage
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tbupddsu	Kernel component usage
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run	UPDD components requested to run at startup

Interfaces

The driver uses a number of system interfaces to post co-ordinate data into the system:

Interface	Type	Description
tbupddsu	Single touch mouse interface	Used to post data into the system as single touch mouse data and created a mouse entry within the Device Manager. This interface can be used in all supported Windows releases, XP thro Win 10: UPDD V6 utilises a signed kernel mode module from UPDD V5 to post touch data into the OS as mouse data, hence the properties show this as a V5 component. It is purely cosmetic that this shows V5. UPDD 6.0.474 and above The mouse module has been resigned in UPDD V6 6.0.474 and now appears as follows: The Driver Version entry is allocated by the WHQL process as a unique identifier for this kernel module.
upddvh	Virtual HID interface	This will only be created on Windows systems with Pen Services available. Used to post data as a compliant HID device to interface with the native touch support built into certain editions of Win 7, 8 and 10. Creates a Virtual HID device per Windows configured monitor within the Device Manager. In this two monitor system there are two Virtual HID entries: When the UPDD configuration tool is used to associate a touch device with a monitor the virtual HID entry is associated as appropriate so that co-ordinate data is directed to the correct monitor. UPDD V6 utilises a signed kernel mode module from UPDD V5 to post touch data into the OS as HID data, hence the properties show this as a V5 component. It is purely cosmetic that this shows V5. UPDD 6.0.474 and above The UPDDVH HID module has been resigned in UPDD V6 6.0.474 and now appears as follows: The Driver Version entry is allocated by the WHQL process as a unique identifier for this kernel module.
w32_events	Direct application interface	Starting with build 407 on Windows we have implemented an experimental interface to post touch data via w32_events directly into an application (residing under the point of touch). This mode of operation injects mouse events directly into an application bypassing the Windows mouse and touch processing. This should satisfy LButtonDown, LButtonUp and MouseMove events. This is useful in a number of ways, such as: to allow concurrent touches to 2 or more applications as long as the applications are on separate touch devices generate mouse clicks within an application without affecting the mouse cursor that may be in use on a separate monitor This feature is not intended to provide a general touch interface as its successful operation is entirely dependent on the implementation of the target application and it can not be used to interact with the desktop. In this mode of operation, touches on the desktop are deliberately blocked and not posted as this interface is specifically aimed at touching within user written applications. The driver locates a Window at the touched position on the desktop and directs mouse events directly to that window. However, Windows creates windows that cover the whole desktop so these must be ignored. Currently windows named 'TabletModeCoverWindow' and 'Windows.UI.Core.CoreWindow' are ignored. Notes. Only single touch per touch device is supported. There is no visual feedback (mouse pointer) except any provide by the target application. Does not support right clicks. This is tested on Windows 10 only; older Windows version are expected to work. Most testing has been with the Chrome browser which works well. This interface will need to be evaluated for suitability on a per case basis. This mode of operation allows for concurrent touches, but it must be noted that in Windows there is the concept of a keyboard focus, which indicates the window into which keyboard events (typed characters) are sent. As only one window can have the keyboard focus an application being controlled by w32_events for the purpose of concurrent usage of applications must either 1. Not change the keyboard focus OR 2. Not be used in conjunction with an application that relies the keyboard focus. It may be possible to extend this feature for specific applications on a case by case basis should the need arise. Applications that form part of the Windows shell, such as Internet Explorer, Explorer, Edge, Outlook are not currently supported. Switching between applications (e.g. by touching the title bar) is not supported, so the target application(s) must be fully visible on the screen. Only one application window should exist at the point of touch as touches could be directed to an underlying hidden window (this method of touch deliberately do not focus the window but at the application at the point of touch and the touch is directed to the application at the top of the application Z list at the point of touch which is not necessarily the one on view) Ensure UPDD interactive touch for the device is disabled such that a steady w32_event touch does not generate a right click at the position of the cursor. Example. Make the settings for a specific UPDD device to utilise the w32_event interface: Control a browser based drawing tool using the w32_event touch interface :

Identified hardware

A UPDD device Device Manager entry is created for each supported USB device physically discovered on the system.

UPDD utilises two different USB interfaces; USBLIB (generic USB library) and alternatively TBUPDDSU kernel module.

USBLIB is the default interface and TBUPDDSU is available to test/try in rare cases that USBLIB has issues with the device.

The global setting usb.use_updd_kernel_driver is set to 1 in software bundles set to use TBUPDDSU.

In this example (implemented via USBLIB) two supported USB devices are connected to the system.

In this example (implemented via kernel UPDD Mouse - TBUPDDSU) the same two supported USB devices are connected to the system.

Processes

In normal circumstances once installation has completed there will be a number of processes running. The actual number will be dependent on the installed components held in the installer. The core driver utilises two processes updd (the user mode driver service) and updd daemon (the background task). If gestures and/or TUIO server is installed these applications will also be running.

Some transitional applications, like the UPDD Test, Calibration and Identify will be listed in the Task Manager when they are running.

However, some UPDD applications will be permanently listed once they are running:
Note: UPDD TUIO / Gestures has been replaced with UPDD Commander - in old versions of the driver you may still see these listed.

Process	Purpose
UPDD	The driver and the API interface.
UPDD STI & Daemon	The driver's daemon task offering a number functions relating to the driver and user interface.
UPDD Commander	Calculate the gesture being performed and makes it available on the driver's API, TUIO server and Win 10 trackpad gestures

Microsoft signing considerations

In a simple driver case, a kernel mode mode driver would be created to support a single device, tested using the Windows Hardware Certification Kit (HCK) and submitted for signing by the Windows Hardware Quality Labs (WHQL). A driver that is digitally-signed by WHQL can then be distributed through the Windows Update program or other Microsoft-supported distribution mechanisms. In the most basic form a signed driver will consist of a .sys file (system file - the driver code), .inf file (setup information file) and a .cat file (catalog file).

This type of driver is likely to stay unchanged for many years and as long as new releases of Windows recognise previous signing protocols the driver could potentially stay valid over a number of Windows releases. It will only require updating or resigning if and when new requirements are introduced with a new release of Windows.

Although UPDD is referred to as a 'driver' it is actually a number of components packaged together that support a variety of touch devices and each package is unique depending on the devices supported within the package. UPDD has been designed such that the kernel mode components are static and remain stable with the bulk of the 'driver' functionality placed in user mode components.

UPDD packages are created to support a selected number of touch devices, hence the .inf file will reflect the devices supported, and utilises the latest user mode driver component - which is under constant development and release.

Not only can kernel mode components be WHQL signed but authenticode certificates can be applied to both the packaged software (the installer) but also the individual components. These certificate are used to verify and identify the software publisher as a legitimate and trusted development source. Authenticode uses cryptographic techniques to verify publisher identity and code integrity. It combines digital signatures with an infrastructure of trusted entities, including certificate authorities (CAs), to assure users that a driver originates from the stated publisher. Authenticode allows users to verify the identity of the software publisher by chaining the certificate in the digital signature up to a trusted root certificate. The hashing technique was originally implemented with SHA1 certificates and this technique was deprecated in January 2017 and replaced with the more secure SHA256 certificates.

UPDD Specifics

UPDD implements two kernel mode components. These are both signed by Microsoft Windows Hardware Labs.

This indicates that these components have passed rigorous tests and can be installed on Windows systems without user intervention.

The modules do not change from build to build and so carry version and timestamp information relevant to the time of WHQL signing as seen in the Device Manager.

HID interface module	Mouse port interface module

Additionally a Windows kernel inbox driver is used for USB communications. This is signed by “Microsoft Windows”

This is delivered as part of a package with an installer information (inf) file and a catalog file updd.cat which carries an authenticode signature

This meets the requirements for installing kernel drivers on Windows as the only driver component is provided by Microsoft WHQL testing and signing is unnecessary.

All UPDD user mode software carry an Authenticode signature as required by Microsoft as per this example of the user mode function driver updd.exe. This allows these programs to be executed without warning.

The installer package also carries an Authenticode signature as required by Microsoft so that the Smartscreen technology does not flag the installer as potential Malware.

Limitations.

Windows XP only supports SHA1 certification which is now obsolete, so signing is not recognised and a user must ignore / skip any installation warnings.

Windows 7 originally only supported SHA1 certification, Windows 7 must be patched to the latest update level to recognise the SHA256 certificates currently used.

Windows 10 introduced Device Guard , a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they operate with many of the properties of mobile devices. Systems can be tested to see if they conform to these new HVCI (Hypervisor Code Integrity) standards using the Microsoft Device Guard Readiness Tool. Currently V6 kernel components do not meet these requirements as the contained components were originally signed with SHA1 certificates. For general usage the WHQL package signature should suffice to warrant the integrity of the package.

In Windows 10 there is a bug in the Device Manager such that the updd.inf driver package is reported as unsigned. This is clearly a bug in Windows as it can easily be demonstrated that the package is signed. Unsigned driver packages cannot be installed on 64 bit Windows systems for example.

Due to the vagaries of the various signing processes some of the components within the packages above are reported as unsigned.

This is unimportant as the packages in question are signed as a whole by MS WHQL. The Windows Driver Verifier does not flag any issues with our drivers.

Note: With a regular UPDD installer package; upon detection of a USB device, Windows will prompt the user to verify if the driver should be installed.

For use in scenarios where the driver is pre-approved and must be installed without intervention a trusted installer package can be provided.