Windows Mobile 6.5 Firewall Socket Filtering

On Windows Mobile 6.5, third-party firewalls filtered incoming and outgoing socket connections by integrating directly into the operating system's networking architecture. Because the OS was built on the Windows CE 5.2 kernel, developers relied on a combination of Winsock Layered Service Providers (LSPs), NDIS Intermediate (IM) drivers, and the native Windows CE IP Filter Driver hook. These integration points allowed security software to intercept traffic at both the transport and application layers, enabling process-level identification, port blocking, and stateful packet inspection.

Winsock Layered Service Providers (LSP)

The primary method for filtering traffic at the socket and application level was through a Winsock Layered Service Provider. Windows Mobile utilized the standard Windows Sockets 2 (Winsock 2) architecture, which supported layered providers inserted directly into the transport communication path.

When an application initiated a socket call (such as connect, send, listen, or accept), the request passed through the custom LSP before reaching the base transport provider. This gave firewalls distinct advantages:

  • Process Association: The LSP executed within the context of the calling application, allowing the firewall to identify the exact executable (e.g., Internet Explorer, an email client, or unknown background malware) attempting to open a socket.
  • Granular Control: The firewall could intercept outbound connection attempts before network packets were generated, prompting the user for permission or immediately rejecting the call via standard Winsock error codes (such as WSAECONNREFUSED).

The Windows CE IP Filter Hook

For lower-level, packet-based socket filtering, developers utilized the built-in Windows CE IP Filter Hook driver mechanism provided by the native TCP/IP stack (tcpstk.dll).

The operating system exposed an API via SetFilterFunction, allowing a kernel-mode driver to register an IP packet filter callback. Once registered:

  • The TCP/IP stack routed all incoming and outgoing IP packets through the firewall’s filter function prior to processing them.
  • The hook received pointers to the packet headers, exposing source and destination IP addresses, protocol numbers (TCP, UDP, ICMP), and port numbers.
  • The filter routine returned predefined action codes, such as PF_PASS to allow the packet through, PF_DROP to silently discard it, or custom directives to handle fragmented packets.

While efficient and lightweight on mobile hardware, the IP Filter Hook lacked inherent knowledge of which specific application initiated a connection, making it best suited for basic port-based rules and network-layer defense.

NDIS Intermediate (IM) Drivers

Advanced third-party security suites implemented NDIS (Network Driver Interface Specification) Intermediate drivers to inspect traffic between physical network adapters (such as Wi-Fi or cellular GPRS/EDGE/3G interfaces) and the upper-level TCP/IP transport protocol.

Sitting at the data-link boundary, an NDIS IM driver:

  • Intercepted raw Ethernet and cellular data frames directly from the miniport driver.
  • Analyzed protocol headers to detect network-level attacks, such as port scans, malformed packets, or spoofing attempts.
  • Dropped malicious incoming packets before the operating system's TCP/IP stack could process them, effectively isolating vulnerable listening sockets from unauthorized remote hosts.

Hybrid Enforcement and Stateful Inspection

Comprehensive firewalls for Windows Mobile 6.5 typically implemented a hybrid architecture. They combined a user-mode or transport-level Winsock LSP with a kernel-mode IP filter or NDIS driver.

When an application initiated an outgoing socket connection, the LSP captured the executable path, target IP, and destination port, creating a state table entry. The lower-level packet filter or driver used this state table to validate incoming response packets, ensuring that incoming traffic was only permitted if it matched an established, authorized outbound session or an explicitly permitted listening port.