Calin's Humble Scanner - User Guide

The Scanning Process

General parameters
Parameters for scan jobs
MAC Discovery phase
Discovery phase
Scan phase
Notes

Note 1: As a feature, CHScanner has the ability to mimic the behaviour of the IP stack of some operating systems and their related tools (the well known ping application is a good example). I have called this feature Operating System Mimic

Note 2: To allow the scan to be performed as fast as possible the scan flow inside a method is performed by port then by host's address. This is usefull especially in the case of UDP related scans but also not to fill up some "slow" NAT firewall or router.

Note 3: For passive scanning see the Passive Scanning section.

The scanning is done based on scan configurations. The scan configurations are stored in files with the chs extension, located in the Configs directory.
Each scan configuration have scan parameters and contains scan jobs.
Each scan jobs is composed of a scan phase and a scan method.

      scan-configuration (.chs file) =
          scan-parameters
          scan-job
          [scan-job]
            ...
          [scan-job]

      scan-job =
          scan-phase + scan-method
          [scan-phase + scan-method]
            ...
          [scan-phase + scan-method]
    
The reason the scanning is done based on presented configuration is to limit the number of packets used.
To help accomplish this the scanning process is done in phases: first find hosts that are alive then scan only those hosts.

Before the scan takes place, the scan-methods are sorted by their phase and then by occurence order.

CHScanner uses the WinPcap library not only to receive data from the network but also to send data to the network. Because this library sends raw packets I had to build the packets starting with the Ethernet header so I had to know the MAC addresses for user supplied IP addresses. This is why I have implemented the ARP protocol (in the case of IPv4) and Network Discovery (in the case of IPv6) and a special phase (MAC Discovery) for them.
To find the MAC addresses, the MAC discovery phase is the first performed one.
This phase is done automatically, it is not specified by any scan-job.

Next, the Discovery phase eliminates "dead" hosts, then, the Scan phase scans the remainin ones.

Here are the scan phases:
These phases are briefly explained in the following sections.

Reducing the address space is done in this way:
Detailed information and the scanning options are explained in the corresponding sections.

General parameters

The window with application's general parameters can be obtained by clicking the Tools button and selecting the Configuration option.
The parameters are:

Parameters for scan jobs

MAC Discovery phase

CHScanner uses the WinPcap library for both sending and receiving data from the network.
Because WinPcap sends raw Ethernet packets, those packets must be constructed starting with the Ethernet header. As each valid Ethernet packet must contain, in it’s header, the source and destination MAC addresses, I had to find them.
The purpose of this phase is to find the MAC addresses for user supplied IP addresses. This is why this phase is ALWAYS executed.

Note

There are however some exceptions to this rule: for the "Ping broadcast" methods I do not need the MAC address of destination hosts. In those particular cases you can use 127.0.0.1 as target address.

Executing the MAC Discovery phase narrows the scanning space because only alive hosts will respond to queries.

The option Show MAC Discovered allows you to use this phase as a discovery method, showing in the scan result the hosts discovered by this method.

However, by implementing the Wake-On-LAN method I had to know the MAC addresses for dead hosts, of course these will not respond to ARP queries. This is the reason that I had to implement an ARP Cache Table.

To extend the functionality, the ARP Cache Table, keeps records for IPv4 and IPv6 addresses.

Regarding the ARP Cache Table, there are these options:
and this options have changed the workflow a bit. Here is how:

Do not use nor update the ARP Cache Table

The workflow is unchanged.

Use ARP Cache Table

The ARP will be used ONLY for the addresses NOT found in the ARP Cache Table !
The ARP Cache Table will NOT be updated.
If the IP addresses in the scanned network are assigned dinamically consider the possibility that the table may NOT be entirelly up to date and you may get false results!

Use and update ARP Cache Table

The ARP will be used ONLY for the addresses NOT found in the ARP Cache Table !
The ARP Cache Table will be updated.
If the IP addresses in the scanned network are assigned dinamically consider the possibility that the table may NOT be entirelly up to date and you may get false results!

Update but NOT use ARP Cache Table

The ARP will be used for all user supplied addresses.
The ARP Cache Table will be updated.

Discovery phase

Scanning a stopped or inexistent IP device is a pointless ant time-consuming operation.
The purpose of Discovery phase is to extract from the user supplied address space the IP addresses that corresponds to "alive" hosts.

In this phase a host will NOT be probed by all selected methods. If a method mark a host as alive, the other methods will not prove his status again !
This is true even inside a method (where is the case). Let's say that you add a TCP SYN scan method in the Discovery phase and provide as port numbers the interval 20-1000. Suppose the scan is in numeric order. The scanner will send a SYN to port 20 then to port 21 and so on until the port 1000 IF and ONLY IF if the target host will not respond. If the target host will respond to one of the packets the target host will be marked alive and the rest of the packets will not be sent. However, due to parallel nature of the scan, even if the host will respond to the first packet, more then one packet may be send to it.

>. The classic way to find if a host is alive is to "ping" it. However, you can also use SYN Scan or ACK Scan for this purpose.

>. If you want to use the for discovery the following methods:

be aware that:

>. The same considerations are true for the IP Protocol Scan method: provide a "generally" not implemented protocol, or protocols, as parameter.

>. If a host is "ARP discovered" normally is marked as "alive" and will NOT be filtered in discovery phase!
If you do not want this behaviour, by example for scanning only the hosts discovered in discovery phase, be sure NOT to check the "Show ARP Discovered" check box !

>.

add tips about "discovery" with DNS and other (find web servers, network printers, ...)

Scan phase

After the MAC Discovery phase and the Discovery phase some host from the user provided address space will be detected as alive. Only those host will be scanned. If the checkbox "Scan All" is checked, all the provided address space is scanned, regardless of the result of MAC Discovery and Discovery phases!

The scanning takes place method by method.
Based on the way the scan methods works, there are the following groups:

Serial scanning methods

These are the slowest ones. The NetBIOS, SNMP, WMI and Shutdown/Reboot scan methods are in this category.

Parallel scanning methods

Most of the scan methods implemented by CHScanner falls in this category.
For each of this methods the scan is performed in parallel limited only by the Max.Sim.Scan parameters.
For host and port based scans, the scan is performed in parallel by port then by host.
For host and protocol based scans, the scan is performed in parallel by protocol then by host.
For host only based scans, the scan is performed in parallel by host (what else?).
This way the speed of the scan process is increased.

One packet scanning methods

These are the most "quiet" ones. These scan methods work by sending a SINGLE packet and wait for responses.
The scan methods in this category are:

For a description of the scan methods see the The Scanning Methods section.

Notes

With the exception of NetBios Scan, SNMP Scan, WMI Scan and Shutdown/Reboot Scan the packets that the application sends are generated internally, starting from the Ethernet level.

The following extensions were tested but NOT implemented:

[ User Guide ]