Skip to main content

Analyzing ICS/SCADA Configurations and Firmware/Validation

1. Procedure​

1.1. Connect to the Device and Upload Configuration​

  • Power On: Ensure the target device is powered on and functioning correctly.
  • Establish Connection: Connect the programming computer to the target device using the appropriate cable and communication settings.
  • Launch Engineering Software: Open the relevant engineering/programming software on the programming computer.
  • Establish Online Connection: Within the software, establish an online connection to the target device. This step will vary depending on the specific software and device type (e.g., browse for device, enter IP address, select serial port).
  • Upload Configuration: Initiate the upload (pull) process to retrieve the current configuration and logic from the device to the programming computer. The specific steps will depend on the software used.
  • Note: The term "Upload" in this context means transferring the data from the device to your computer.
  • Save the Configuration: Save the uploaded configuration and logic to a designated temporary location, ensuring a unique and descriptive filename (e.g., Device_Config_Live_YYYYMMDD_HHMM.zip, or the native file format).

1.2. Comparing Configurations (Live vs. Known Good)​

  • Open Known-Good Configuration: Open the known-good (as-built or last validated) configuration file in the engineering software or a compatible file viewer.
  • Open Live Configuration: Open the recently uploaded configuration file (from step 6.1) in the engineering software or a compatible file viewer.
  • Utilize Comparison Tools: Use the built-in comparison features within the engineering software (if available) or a suitable third-party file comparison tool to identify differences between the two configurations. This may involve comparing:
    • Hardware Configuration: Differences in installed modules, I/O assignments, and network settings.
    • Logic (Program Blocks/Routines): Differences in program code, functions, and data blocks.
    • Tags/Variables: Differences in tag/variable definitions, data types, and initial values.
    • Communication Settings: Differences in network parameters, protocols, and addresses.
  • Alternative Comparison Methods (if native software comparison is limited):
    • Text Export and diff: If the engineering software allows exporting the ladder logic or other configuration elements to a text-based format (e.g., mnemonics, structured text):
      • Export both the live configuration and the known-good configuration into the text format.
      • Use a text comparison tool (e.g., diff or sdiff on Linux) to compare the two text files. Example: diff -u known_good.txt live_config.txt. diff will output only the lines that are different between the files, while sdiff will display them side-by-side.
diff -u known_good.txt live_config.txt
  • Analyze the output to identify differences in the program logic. According to Emerson Exchange 365, PAC Machine Edition allows copying and pasting ladder logic mnemonics to a text document, and also exporting logic blocks as XML files.
  • OpenPLC Project: For systems utilizing OpenPLC or compatible with IEC 61131-3 standards:
    • Load both the known-good and live configurations into the OpenPLC editor.
    • Visually compare the ladder logic or other program elements within the editor.
    • If OpenPLC supports exporting to a text format, follow the "Text Export and diff" method described above.
  • Document Differences: Carefully document all identified differences, including the specific sections, lines of code, or parameters that vary. Prioritize critical differences (e.g., changes to control logic, safety parameters, communication settings).

1.3. Firmware Validation (If Hash/Checksum Available)​

  • Retrieve Current Firmware Information: While connected to the device, access the device status or diagnostic information to determine the currently running firmware version. This may be available through the engineering software's online diagnostics, a device's web interface, or other vendor-specific methods.
  • Obtain Vendor Hash/Checksum: If the vendor provides hash or checksum values for specific firmware versions, retrieve the value corresponding to the firmware version found on the device.
  • Calculate Local Hash (if necessary): If the vendor does not provide a hash/checksum but you have a known-good firmware file, use a hashing tool to calculate its hash (e.g., MD5, SHA-256).
# For MD5:
md5sum /path/to/firmware_file

# For SHA256:
sha256sum /path/to/firmware_file
  • Compare Values: Compare the hash/checksum value obtained from the device (if directly available) or the calculated hash of the known-good firmware file with the vendor-provided value or a previously validated hash. A different hash value means that the integrity of the file is not preserved.
# Using echo and md5sum -c:
echo "expected_md5_hash */path/to/firmware_file" | md5sum -c -

# Using echo and sha256sum -c:
echo "expected_sha256_hash */path/to/firmware_file" | sha256sum -c -

# Using a checksum file:
md5sum -c checksum_file.md5
sha256sum -c checksum_file.sha256

# Comparing hashes directly with diff:
diff <(sha256sum file1) <(sha256sum file2)
  • Document Findings: Record the current firmware version and the outcome of the hash/checksum validation (match or mismatch). A mismatch indicates potential tampering or corruption and requires further investigation.