wording and formatting updates

documentation/modules/auxiliary/admin/scada/phoenix_command.md

@@ -1,24 +1,30 @@
-PhoenixContact Programmable Logic Controllers are built are using a variant of ProConOS. 
+PhoenixContact Programmable Logic Controllers are built are using a variant of
- Communicating using a proprietary protocol over ports TCP/1962 and TCP/41100 or TCP/20547.
+ProConOS. The communicate using a proprietary protocol over ports TCP/1962 and
-It allows a remote user to read out the PLC Type, Firmware and Build number on port TCP/1962.
+TCP/41100 or TCP/20547.  This protocol allows a user to remotely determine the
-And also to read out the CPU State (Running or Stopped) AND start or stop the CPU on 
+PLC type, firmware and build number on port TCP/1962.  A user can also
-port TCP/20547 (confirmed for the PLC series ILC 15x and 17x)
+determine the CPU State (Running or Stopped) and start or stop the CPU.
-or   TCP/41100 (confirmed for the ILC 39x series)
+
-other series may or may not work, a very big chance that they will
+This functionality is confirmed for the PLC series ILC 15x and 17x on TCP port
+20547, and for the ILC 39x series on TCP port 41100. Other series may or
+may not work, but there is a good chance that they will
 
 ## Vulnerable Application
 
-This is a hardware zero-day vulnerability that CANNOT be patched, the only mittigation is pulling the plug (literally),
+This is a hardware zero-day vulnerability that CANNOT be patched. Possible
-adding a separate network in front of it (Firewall, Router, IDS, IPS, network segmentation, etc...)
+mitigations include: pulling the plug (literally), using network isolation
-or not allowing bad people on your network .
+(Firewall, Router, IDS, IPS, network segmentation, etc...) or not allowing bad
- 
+people on your network .
-In general most, if not all, PLC's (computers that control engines, robots, conveyor belts, sensors, camera's, doorlocks, CRACs ...)
+
-have this vulnerability where, using their own tools, remote configuration and programming can be done *WITHOUT* authentication. 
+Most, if not all, PLC's (computers that control engines, robots, conveyor
-Investigators and underground hackers are just now creating simple tools to convert the often proprietary protocols into (simple) scripts.
+belts, sensors, camera's, doorlocks, CRACs ...) have vulnerabilities where,
- 
+using their own tools, remote configuration and programming can be done
-The most important word here is proprietary. Right now the only thing stopping very bad stuff from happening.
+*WITHOUT* authentication.  Investigators and underground hackers are just now
-PhoenixContact uses an (unnamed?) low-level protocol for connection, information exchange and configuration of its PLC devices.
+creating simple tools to convert the, often proprietary, protocols into simple
-This script utilises that protocol for finding information and switching the PLC mode from STOP to RUN and vice versa
+scripts.  The operating word here is proprietary. Right now, the only thing
+stopping very bad stuff from happening.  PhoenixContact uses an (unnamed?)
+low-level protocol for connection, information exchange and configuration of
+its PLC devices.  This script utilizes that protocol for finding information
+and switching the PLC mode from STOP to RUN and vice-versa.
 
 ## Verification Steps
 
@@ -72,38 +78,44 @@ Module options (auxiliary/admin/scada/phoenix_command):
    RPORT                       no        Set action port, will try autodetect when not set
 ```
 
-By default, the module only reads out the PLC Type, Firmware version, Build date and current CPU mode (RUNning or STOPped)
+By default, the module only reads out the PLC Type, Firmware version, Build
+date and current CPU mode (RUNing or STOPed)
 
-The first three pieces of data (Type, Firmware & Build) are always found on port TCP/1962 
+The first three pieces of data (Type, Firmware & Build) are always found on
- (there is no way of changing that port on the PLC, so also no reason to change the 'RINFOPORT' option)
+port TCP/1962 (there is no way of changing that port on the PLC, so also no
+reason to change the 'RINFOPORT' option)
 
- The CPU mode uses a TCP port depending on the PLC Type, the module will automatically detect the type and port to use,
+The CPU mode uses a TCP port depending on the PLC Type, the module will
-but can be overridden with the 'RPORT' option, however no real reason to configure it.
+automatically detect the type and port to use, but can be overridden with the
---> If 'RPORT' is set for some reason (e.g. because of an earlier "setg RPORT" command), it can be unset with:
+'RPORT' option, however no real reason to configure it.
+
+--> If 'RPORT' is set for some reason (e.g. because of an earlier "setg RPORT" command), it can be
+	unset with:
 ```
 msf auxiliary(phoenix_command) > unset RPORT
 Unsetting RPORT...
 ```
 
 **The ACTION option**
+
 Action only has four (4) possible values:
 
-By default, the module will do nothing to the PLC, therefore No Operation or 'NOOP'
+By default, the module will do nothing to the PLC, therefore No Operation or 'NOOP':
 ```
 msf auxiliary(phoenix_command) > set ACTION NOOP
 ```
 
-The PLC can be forced to go into STOP mode, meaning it stops all execution and all outputs are set to low
+The PLC can be forced to go into STOP mode, meaning it stops all execution and all outputs are set to low:
 ```
 msf auxiliary(phoenix_command) > set ACTION STOP
 ```
 
-The PLC can be forced to go into RUN mode, it keeps running it was or it will start executing its current boot programming
+The PLC can be forced to go into RUN mode, where it keeps running it was or it will start executing its current boot programming:
 ```
 msf auxiliary(phoenix_command) > set ACTION START
 ```
 
-The module can also just read out the CPU mode and then reverse whatever it finds, RUN becomes STOP, STOP becomes RUN
+The module can also just read out the CPU mode and then reverse whatever it finds, RUN becomes STOP, STOP becomes RUN:
 ```
 msf auxiliary(phoenix_command) > set ACTION REV
 ```