Add Windows XP/2003 network support to netscan#1994
Open
ricardojrdez wants to merge 2 commits into
Open
Conversation
windows.netscan previously raised NotImplementedError for Windows XP / Server 2003 (NT 5.1/5.2), since those versions use a different family of network pool structures (TCPT/TCPA) than Vista+ (TcpL/TcpE/UdpA). This folds XP/2003 support into netscan's existing version gating rather than adding separate plugins, so users get one unified network view across all versions. - netscan-winxp-x86.json: ISF defining _TCPT_OBJECT (tag TCPT, TCP connections) and _ADDRESS_OBJECT (tag TCPA, bound/listening sockets) for Windows XP SP2 x86. - extensions/network_xp.py: class_types exposing local/remote address, protocol, create time, and is_valid() filtering to reject tag-collision false positives. - netscan: determine_tcpip_version returns the XP ISF + class types for NT 5.x x86; create_netscan_constraints grows an XP (TCPT/TCPA) branch; the generator renders XP objects into the shared TreeGrid, resolving the Owner column via a one-shot pslist PID->name map. Validated on a Zeus XP SP2 image: netscan now lists 22 network objects (2 connections + 20 sockets) including the C2 connection 172.16.176.143:1054 -> 193.104.41.75:80 owned by svchost.exe (PID 856). The Vista+ path is unchanged (regression-checked on a Win7 x86 image: 102 rows, normal TcpL/TcpE/UdpA output). Note: PAE XP/Win7 images additionally require the separate PAE DTB detection fix for the kernel layer (and thus Owner-name resolution) to work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
netstat performs active enumeration by walking tcpip.sys's live tracking structures (partition tables, port bitmaps), which only exist on Vista+. Since netscan's symbol-table loader now returns an XP ISF for NT 5.x (rather than raising), netstat on XP would otherwise fail with a confusing "PartitionTable: Unknown symbol" error. Add an explicit NT 5.x guard that warns and points the user to windows.netscan (which does support XP via TCPT/TCPA pool scanning). Vista+ behaviour is unchanged (regression-checked on a Win7 x86 image). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
windows.netscan previously raised NotImplementedError for Windows XP / Server 2003 (NT 5.1/5.2), since those versions use a different family of network pool structures (TCPT/TCPA) than Vista+ (TcpL/TcpE/UdpA). This folds XP/2003 support into netscan's existing version gating rather than adding separate plugins, so users get one unified network view across all versions.
Validated on a Zeus XP SP2 image: netscan now lists 22 network objects (2 connections + 20 sockets) including the C2 connection 172.16.176.143:1054 -> 193.104.41.75:80 owned by svchost.exe (PID 856). The Vista+ path is unchanged (regression-checked on a Win7 x86 image: 102 rows, normal TcpL/TcpE/UdpA output).
Note: PAE XP/Win7 images additionally require the separate PAE DTB detection fix for the kernel layer (and thus Owner-name resolution) to work.