TZWorks LLC
System Analysis and Programming
www.tzworks.com


TZWorks®
Network Xfer Client/Server Utility - nx

(Version 0.42, nx protocol ver: 0.08)



Information about our End User's License Agreements (EULAs)
for software on TZWorks, LLC Website www.tzworks.com

User Agreement

TZWorks LLC software and related documentation ("Software") is governed by separate licenses issued from TZWorks LLC. The User Agreement, Disclaimer, and/or Software may change from time to time. By continuing to use the Software after those changes become effective, you agree to be bound by all such changes. Permission to use the Software is granted provided that (1) use of such Software is in accordance with the license issued to you and (2) the Software is not resold, transferred or distributed to any other person or entity. Refer to your specific EULA issued to for your specific the terms and conditions. There are 3 types of licenses available: (i) for educational purposes, (ii) for demonstration and testing purposes and (iii) business and/or commercial purposes. Contact TZWorks LLC (info@tzworks.com) for more information regarding licensing and/or to obtain a license. To redistribute the Software, prior approval in writing is required from TZWorks LLC. The terms in your specific EULA do not give the user any rights in intellectual property or technology, but only a limited right to use the Software in accordance with the license issued to you. TZWorks LLC retains all rights to ownership of this Software.

Export Regulation

The Software is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations. The Export Control Classification Number (ECCN) for the Software is 5D002, subparagraph C.1. The user shall not, directly or indirectly, export, re-export or release the Software to, or make the Software accessible from, any jurisdiction or country to which export, re-export or release is prohibited by law, rule or regulation. The user shall comply with all applicable U.S. federal laws, regulations and rules, and complete all required undertakings (including obtaining any necessary export license or other governmental approval), prior to exporting, re-exporting, releasing, or otherwise making the Software available outside the U.S.

Disclaimer

The user agrees that this Software made available by TZWorks LLC is experimental in nature and use of the Software is at user's sole risk. The Software could include technical inaccuracies or errors. Changes are periodically added to the information herein, and TZWorks LLC may make improvements and/or changes to Software and related documentation at any time. TZWorks LLC makes no representations about the accuracy or usability of the Software for any purpose.

ALL SOFTWARE ARE PROVIDED "AS IS" AND "WHERE IS" WITHOUT WARRANTY OF ANY KIND INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL TZWORKS LLC BE LIABLE FOR ANY KIND OF DAMAGE RESULTING FROM ANY CAUSE OR REASON, ARISING OUT OF IT IN CONNECTION WITH THE USE OR PERFORMANCE OF INFORMATION AVAILABLE FROM THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY DAMAGES FROM ANY INACCURACIES, ERRORS, OR VIRUSES, FROM OR DURING THE USE OF THE SOFTWARE.

Removal

The Software are the original works of TZWorks LLC. However, to be in compliance with the Digital Millennium Copyright Act of 1998 ("DMCA") we agree to investigate and disable any material for infringement of copyright. Contact TZWorks LLC at email address: info@tzworks.com, regarding any DMCA concerns.


About the nx Tool (top)

nx is a command line tool that can act as either a client or server for the purposes of transferring data from more than one computer (acting as clients) to a central computer (acting as the server). The server in this case, would be the forensic workstation gathering information during an incident response, while the clients would be those computers that are under investigation.

There are other tools available that perform this function such as netcat and cryptcat. nx, however, focuses on (a) secure collection, (b) archiving the file metadata, and (c) creating a complete log file of all the transactions that occurred. For extracted files, an MD5 hash is logged as well as the original directory path that the file is taken from.

nx operates in one of two modes to transfer data: (a) pulling data from standard input and (b) explicitly copying files. The transport used is TCP/IP with the data content encrypted in a RC4 stream cipher. To ensure data integrity from the client computer to the final archived file on the server, a hash is computed at client side before transmission, and during receipt, by the server. A mismatch in hashes results in the archive file being labeled as having errors. Finally, the results can be controlled by the client end, meaning each specific data transfer is outputted to a separate file. Labels and filenames are allowed to be passed during each data transfer, which are then consumed by the server and acted upon accordingly. The number of tunable parameters at this point is still limited, but as suggestions come in, additional flexibility can be added.

Currently, this initial version is restricted to just IPv4. Depending on need, IPv6 can be added. While there are compiled versions for Windows, Linux and Mac OS X, the architecture is such that each one is designed to cooperate with another instance operating on a different OS (eg. use nx on a Linux box as the server and use nx on a Windows client box to send data to the server).

To use this tool, an authentication file is required to be in the same directory as the binary in order for the tool to run.


Usage (top)

One can display the menu options by typing in the executable name without parameters. Below is the menu with the various options. Details of each option can be found here.

    Usage:

     Forensics workstation (server) setup
       nx -server -ip <ip addr> -port <port #> -dir <results dir> [options]

     Client target usage
       nx -ip <server ip addr> -port <server port #> [options]

     Options for server
        -redirect <ip addr>          = where client sends data to
        -scripts <dir for scripts>   = scripts available for minx clients

     Options for both client/server
        -key "password phrase"       = set the key for the transmitted data

     Options for client
        -name "filename that server uses to store results"
        -comment "text to track w/ output"
        -binary          = adds no formatting to the output
        -copyfile <file> = file to send to the server
        -ping            = checks on server and displays time stats
        -quiet           = don't echo what is being sent
        -cust_id <name>  = associate nx transactions w/ this client label
        -host_id <name>  = associate nx transactions w/ this host label
        -pipe            = use stdin to pipe in cmds

     Options for client when using -pipe
        -copyfile                 = stdin has a filename per line to xfer
        -filter <*partial*|*.ext> = filters stdin data

     Examples of running client via piping cmds via stdin or copying files
       ipconfig /all | nx -pipe -ip <serv> -port <#> -name ipconfig_all.txt
       netstat -anob | nx -pipe -ip <serv> -port <#> -name netstat_anob.txt
       wmic process list full | nx -pipe -ip <serv> -port <#> -name wmiproc.txt
       dir c:\*.pdf /b /s | nx -ip <serv> -port <#> -copyfile -pipe

Server setup example

    nx -server -dir c:\archive\case1\ -ip  192.168.1.10  -port  2222 

Client usage example, based on above server setup

a. ping the server to ensure that we are up and running

    nx -ip 192.168.1.10 -port 2222 -ping

b. Copy all the prefetch files to the server.

    dir c:\windows\prefetch\*.pf /b /s | nx -ip 192.168.1.10 -port 2222 -copyfile -pipe

c. Enumerate all the networks connections and send the output into stdin

     netstat -a | nx -ip 192.168.1.10 -port 2222 -name netstat_a.txt -comment "netstat -a"

Output filename characteristics

All files that are generated on the server side use the following syntax:

    <filetime>_<md5hash>_<filename that was provided by client>

Unfortunately, this makes for long filenames. For those client commands that did not have an explicit filename to use, the word 'cmd' will be used for the filename portion at the end.

Finally, there will be one results file in CSV (comma separated value) format that will contain appropriate metadata that was gathered during the transaction. This results file uses the following syntax:

     <readable date>_<readable time>_results.csv

          <readable date> = yyyy_mm_dd
          <readable time> = hhmm_ss_msec  , where hhmm = 24 hour format

Handling Volume Shadow Copies (top)

For starters, to access Volume Shadow copies, one needs to be running with administrator privileges. Also, it is important to note that, Volume Shadow copies as is discussed here, only applies to Windows Vista, Win7, Win8, and beyond. It does not apply to Windows XP.

To make it easier with the syntax, we've built in a shortcut syntax in order to more easily access a specific file in a specified Volume Shadow copy, via the %vss% keyword. This internally gets expanded into \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy. Thus, to access index 1 of the volume shadow copy, one would combine the keyword and index, index, (eg. %vss%1) in front of the normal path of the file. For example, to access a user hive located in the testuser account from the HarddiskVolumeShadowCopy1, the following syntax can be used:

    nx -ip 192.168.1.10 -port 2222 -copy %vss%3\Users\testuser\ntuser.dat

To determine which indexes are available from the various Volume Shadows, one can use the Windows built-in utility vssadmin, as follows:

    vssadmin list shadows

    -- or to filter out extraneous detail --
    
    vssadmin list shadows | find /i "volume"

While the amount of data can be voluminous from that above command, the keywords one needs to look for are names that look like this:


    Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
    Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
    ...

From the example above, notice the number after the word HarddiskvolumeShadowCopy. This would be the number that is appended to the %vss% keyword.


Server Log file (top)

The nx server side will automatically generate a log file to record all the actions between the client and server. The fields recorded are as follows:

Field Description
status Whether the transmission from the client was successful or not
Server Date/Time Timestamp of the server in UTC (relative to the server's clock) for the client transmission
Target Date/Time Timestamp of the client in UTC (relative to the client's clock) during the contact with a request to send data
Target Client's ID. Defaults to the client's IP address, but can be changed using -cust_id option
Host Client's host identifier. Defaults to the client's computer name, but can be changed using -host_id option
Admin Whether the client is running with admin privs or not
Orig Src IP Client's IP address used to send data to the server
Orig Src Port Client's Port used to send data to the server
Type Data Whether a file was copied or a comment was sent, etc
Comment Field defined by client to use as necessary
File MD5 hash Computed hash of the file sent from the client to the server
File recvd Original path of the file copied (from the perspective of the client)
Size Size of the data received from the client
adate Access timestamp in UTC of the original file sent
cdate Create timestamp in UTC of the original file sent
mdate Modify timestamp in UTC of the original file sent

List of options (top)

Server Options

Option Description
-server Server option that specifies this session as the server. Without this option, the session is the client.
-ip IP address of the server (used for both client and server sessions). The syntax is: -ip <server IP address>.
-port Port address of the server (used for both client and server sessions). The syntax is: -port <server port address>.
-dir Server required option to specify what directory to dump the data coming from the client (not used for the client). The syntax is: -dir <results directory>.
-key Client and Server option. If network encryption is required, this is the symmetric key to use. If used, the same key is needed for both the client and server. The syntax is: -key <password phrase>.
-redirect Server option. Tells the server that the client will initially route packets to the TCP/IP address specified. Otherwise, without this option, the server will assume client is sending packets directly to server IPv4 address. Without using this option, if a redirector is used between client and server, server will ignore packets that client targets to a redirector IP address. This option is only available with site licenses. The syntax is: -redirect <IPv4 address of where the client sends data to>
-scripts Server option that tells the server which folder has the configuration files (scripts) that can be queried by the client (only useful if using a minx client).
-no_whitespace Used to affect the formatting of the server log file. Used in conjunction with -csv option to remove any whitespace between the field value and the CSV separator.
-csv_separator Used to affect the formatting of the server log file. Used in conjunction with the -csv option to change the CSV separator from the default comma to something else. Syntax is -csv_separator "|" to change the CSV separator to the pipe character. To use the tab as a separator, one can use the -csv_separator "tab" OR -csv_separator "\t" options.
-dateformat Output the date using the specified format. Default behavior is -dateformat "yyyy-mm-dd". Using this option allows one to adjust the format to mm/dd/yy, dd/mm/yy, etc. The restriction with this option is the forward slash (/) or dash (-) symbol needs to separate month, day and year and the month is in digit (1-12) form versus abbreviated name form.
-timeformat Used to affect the formatting of the server log file. Output the time using the specified format. Default behavior is -timeformat "hh:mm:ss.xxx" One can adjust the format to microseconds, via "hh:mm:ss.xxxxxx" or nanoseconds, via "hh:mm:ss.xxxxxxxxx", or no fractional seconds, via "hh:mm:ss". The restrictions with this option is that a colon (:) symbol needs to separate hours, minutes and seconds, a period (.) symbol needs to separate the seconds and fractional seconds, and the repeating symbol 'x' is used to represent number of fractional seconds. (Note: the fractional seconds applies only to those time formats that have the appropriate precision available. The Windows internal filetime has, for example, 100 nsec unit precision available. The DOS time format and the UNIX 'time_t' format, however, have no fractional seconds). Some of the times represented by this tool may use a time format without fractional seconds and therefore will not show a greater precision beyond seconds when using this option.
-pair_datetime Used to affect the formatting of the server log file. Output the date/time as 1 field vice 2 for csv option

Client Options

Option Description
-ip IP address of the server (used for both client and server sessions). The syntax is: -ip <server IP address>.
-port Port address of the server (used for both client and server sessions). The syntax is: -port <server port address>.
-key Client and Server option. If network encryption is required, this is the symmetric key to use. If used, the same key is needed for both the client and server. The syntax is: -key <password phrase>.
-name Option for the client to request the server to use the specified filename to archive the results. The syntax is: -name <filename>.
-comment Option for the client to send to the server to make a comment in the logs stored on the server session side. The syntax is: -comment <"phrase">.
-binary Option for the client that says not to add any formatting to the data that is read from the target computer and sent to the server.
-copyfile Option for the client to copy a specified file and send it to the server. The syntax is: -copyfile <file to copy>.
-ping Option for the client to check whether the server is up and synchronized time statistics. These statistics are recorded in the server side logs.
-quiet Option for the client to not echo to the user (client side) what is being sent to the server.
-cust_id Option for the client to identify itself to the server with a unique client label. This label is associated with all the files sent by this client. The syntax is: -cust_id <label>.
-host_id Option for the client to identify itself to the server with a unique host label. This label is associated with all the files sent by this client. The syntax is: -host_id <label>.
-pipe Used to pipe files or commands into the tool via STDIN (standard input). Each file passed in is parsed in sequence. Below are some examples:

    ipconfig /all | nx -pipe -ip <serv ip> -port <port #> -name ipconfig_all.txt
    netstat -anob | nx -pipe -ip <serv ip> -port <port #> -name netstat_anob.txt
    wmic process list full | nx -pipe -ip <serv ip> -port <port #> -name wmic_proc.txt
    dir c:\*.pdf /b /s | nx -pipe -ip <serv ip> -port <port #> -copyfile
        
-filter Filters data passed in via stdin via the -pipe option. The syntax is -filter <"*.ext | *partialname* | ...">. The wildcard character '*' is restricted to either before the name or after the name.

Known Issues (top)

1. There is an issue between the output of Windows and Unix based OS's; namely how the Carriage Return (CR) is used at the end of a line. When reading input from stdin, for example, Windows expects one to put a CRLF (2 separate characters). Even though the input may have only been one character (eg LF), hence the reason for the -binary option, if you do not want this behavior.

Unix OS variants do not have the above issue. So the default behavior for Windows when piping input into stdin will read up to the LF and then change it to a CRLF, otherwise you would have issues reading the output in some of the text editors (such as notepad).

2. Client/Server versions of nx are sync'd up with each other from a crypto keying standpoint (albeit a very simple technique is used and not sophisticated). It is just to ensure that newer versions of nx don't get used with older versions.


Authentication and License File (top)

This tool has authentication built into the binary. The primary authentication mechanism is the digital X509 code signing certificate embedded into the binary (Windows and macOS).

The other mechanism is the runtime authentication, which applies to all the versions of the tools (Windows, Linux and macOS). The runtime authentication ensures that the tool has a valid license. The license needs to be in the same directory of the tool for it to authenticate. Furthermore, any modification to the license, either to its name or contents, will invalidate the license.

Limited versus Demo versus Full in the tool's output banner

The tools from TZWorks will output header information about the tool's version and whether it is running in limited, demo or full mode. This is directly related to what version of a license the tool authenticates with. The limited and demo keywords indicates some functionality of the tool is not available, and the full keyword indicates all the functionality is available. The lacking functionality in the limited or demo versions may mean one or all of the following: (a) certain options may not be available, (b) certain data may not be outputted in the parsed results, and (c) the license has a finite lifetime before expiring.


Version history (top)


References (top)

  1. Gary Wright and Richard Stevens, TCP/IP Illustrated, Vol 2, The Implementation, 1995
  2. Douglas Comer & David Stevens, Networking with TCP/IP Client-Server Programming and applications, 2001
  3. Jones, Bejtlick, Rose, Real Digital Forensics, Computer Security and Incident Response, 2006
  4. zlib library version 1.2.8, April 28th, 2013, by Jean-loup Gailly and Mark Adler.