The Stuxnet malware attack has provided strong evidence for the development of a forensic capability to aid in thorough post-incident investigations. Current live forensic tools are typically used to acquire and examine memory from computers running either Windows or Unix. This makes them incompatible with embedded devices found on SCADA systems that have their own bespoke operating system. Currently, only a limited number of forensics tools have been developed for SCADA systems, with no development of tools to acquire the program code from PLCs. In this paper, we explore this problem with two main hypotheses in mind. Our first hypothesis was that the program code is an important forensic artefact that can be used to determine an attacker's intentions. Our second hypothesis was that PLC debugging tools can be used for forensics to facilitate the acquisition and analysis of the program code from PLCs. With direct access to the memory addresses of the PLC, PLC debugging tools have promising functionalities as a forensic tool, such as the "Snapshot" function that allows users to directly take values from the memory addresses of the PLC, without vendor specific software. As a case example we will focus on PLC Logger as a forensic tool to acquire and analyse the program code on a PLC. Using these two hypotheses we developed two experiments. The results from Experiment 1 provided evidence to indicate that it is possible to acquire the program code using PLC Logger and to identify the attacker's intention, therefore our hypothesis was accepted. In Experiment 2, we used an existing Computer Forensics Tool Testing (CFTT) framework by NIST to test PLC Logger's suitability as a forensic tool to analyse and acquire the program code. Based on the experiment's results, this hypothesis was rejected as PLC Logger had failed half of the tests. This suggests that PLC Logger in its current state has limited suitability as a forensic tool, unless the shortcomings are addressed.