Micrologix 1100 and EasyBuilder Pro HMI

technojuggler

Member
Join Date
May 2015
Location
home
Posts
9
Hi all,

This is going to be a fairly long post. I am researching into SCADA security and would appreciate if anyone could provide any inputs for the same. I am trying to establish a communication between a Micrologix 1100 device and a HMI( I was thinking of EasyBuilder pro for its easy availability). I need to run a very basic program running on the PLC which could be controlled from the HMI, just a simple turn on and turn off would also do. I just need to tap into between and try to compromise the Ethernet/IP protocol connected through a RJ45 cable using the tool I developed.

I have established a communication using a RSlinx through a RJ 45 connector and I am able to capture the ethernet/ip packets basically asking for the device.

My questions are:

1. When I try to add the device in EasyBuilder pro it has a option for Ethernet-IP/DF1, will this selection be suitable for connection through RJ45?

2. Can anyone help me write a simple program just to turn ON and OFF using a toggle switch on the HMI (EasyBuilder Pro) or any other recommended free HMI?

3. Also is there any other HMI advisable?

4. Is it possible to read a program from a already programmed PLC? I mean the program which is already dumped onto the PLC/

I am new to the PLC world and kind of getting my head around it.

Any help or inputs would be really appreciated. Please do ask for clarification if at all my post wasn't clear.

Thanks!
 
Last edited:
Hi,

Have used the Weintek HMIs numerous times with pretty much most of the Rockwell range (Compact/ControlLogix, most of the Micrologix and the Micro800 series) all very successfully, with a reasonably short learning curve.

1. When I try to add the device in EasyBuilder pro it has a option for Ethernet-IP/DF1, will this selection be suitable for connection through RJ45? Yes
2. Can anyone help me write a simple program just to turn ON and OFF using a toggle switch on the HMI (EasyBuilder Pro) or any other recommended free HMI? See PLC addressing info below
3. Also is there any other HMI advisable? Of course - there are many alternatives - it's whatever suits your budget/application and software user friendliness!
4. Is it possible to read a program from a already programmed PLC? I mean the program which is already dumped onto the PLC/ - Yes. Although without the offline (documented) file, you will only see the raw ladder logic (assuming it's not password protected of course!)

A few pointers for the EBPro/Rockwell address format used in Micrologix:

I:0.0/0 - I1 00000
I:0.1/1 [I:0/17) - I1 00101
B3:0/0 - B3 00000
B3:2/8 - B3 00208
B15:5/2 - Bfn 1500502
N7:0 - N7 000
N12:0 - Nfn012000
T4:0.PRE - T4SV 001
T4:4.ACC - T4PV 003

Just a few examples to help get you started. Once you get familiar with the addressing format, it's fairly straight forward to build up your HMI application...

Regards,

Rob
 
Hi again,

I was able to download a basic program with just one rung into the PLC. Just a simple on/off program. Giving input at I:0/0 a simple toggle switch and getting the output on O:0/1. How would the addressing conventions go in the easy builder pro?

The way I understand it is: i'll assign a write from the HMI using a toggle, so the write address should be what for the PLC?? I1 00000??

When I read it on the HMI should the read location be O0 ??

Too confused of what should be the read/write addresses with respect to the HMI?

Could you please discuss with respect to the inputs and outputs i specified? Will help me understand better? Also the addressing formats? DDDdd what would they stand for? I would appreciate the clarification.

Thank you so much again.

And sorry for being so naive. Kind of on a deadline with no time to research.
 
technojuggler said:
...I am researching into SCADA security...I just need to tap into between and try to compromise the Ethernet/IP protocol connected through a RJ45 cable using the tool I developed...I have established a communication using a RSlinx through a RJ 45 connector and I am able to capture the ethernet/ip packets basically asking for the device.

I, and others, have helped you in a related thread, and was happy to have done so, but I had not yet seen this thread.

There is a fine line between helping someone do valid security research on industrial protocol communications and helping someone in developing a tool to covertly sniff or perhaps even disrupt or manipulate data packets. So forgive my curious and somewhat suspicious nature.

On the face of it, you appear genuine, and while legitimate packet sniffing is a relatively common practice, what you appear to be attempting is not. What makes me most suspicious is the fact you have little to no PLC/SCADA experience, yet you are delving into security vulnerabilities within that same field? This would normally be the role of an experienced person, familiar with the many aspects of industrial communications and their potential weaknesses.

You may possess such experience, but from the above it's hard to tell.

Perhaps, if you declared your intentions in a little more detail, then I (and perhaps others?) might not be so suspicious.

Regards,
George
 
LOL. I assure you of this being for legitimate university research. While my research area lies in penetration testing of computer networks and establishing proof of concept of the vulnerabilities that lie in the protocols therein. And now I am venturing into SCADA protocols, Ethernet/IP protocol being one of the few. My colleagues and I have worked on demonstrating the vulnerabilities in the DNP3 protocol in the past, which was demonstrated using a free open source project to generate the traffic. Whereas in case of Ethernet/IP there's no way to generate a traffic and so I need to set up a very basic general Ethernet/IP network for demonstration.

Here's the link to the paper
http://crpit.com/confpapers/CRPITV161Rodofile.pdf

You and all must have heard of SCAPY a command line packet capture and manipulation tool(a open source project). I have developed a library for Ethernet/IP which would essentially detect the specific fields within the packets which would be then helpful to manipulate the packets and provide a proof of concept for the attacks on the SCADA systems. Its just the protocols that I am working with and in a very generalized way. It doesn't demand to understand the architecture and deployment of SCADA systems at least at this point. So, that proves my naiveness in the field.

I applaud your curiosity and the want to maintain a legit forum. And its good to be suspicious. I hope I have assured you enough to help me with it! :)

Cheers!
 
Last edited:
Thank you for understanding my concerns, even if they appear a bit "conspiracy theorist" like. This is not my Forum to Police, it belongs to us all. But I do watch over it as best I can, as do many others.

I had read about SCAPY before but I have never used it.

I've read the DNP3 paper and it made for an interesting read. It looks and sounds like a very interesting line of research and I am now somewhat intrigued. Especially on the subject of the Ethernet/IP protocol and it's potential vulnerabilities.

Do you carry out any research on the potential vulnerabilities in advance of carrying out these attacks i.e. Other case studies or reports of real world attacks, and base your attacks on those?

Or do you just use a template of predefined attacks, similar to those in the DNP3 Paper?

Back to your question...

As your line of work/research does not require an indept knowledge of PLCs and their methods of programming and addressing, I'll keep things simple while giving you a basic grounding on what's what.

technojuggler said:
...The way I understand it is: i'll assign a write from the HMI using a toggle, so the write address should be what for the PLC?? I1 00000??...

You are working off the concept of writing from the HMI toggle switch to the same Input address as the wired toggle switch in the PLC, in order to execute the same basic rung of logic. This would not be a general practice.

What address you write to in the MicroLogix depends on how you have it programmed, but as a rule of thumb, you should not write to PLC Input addresses from anywhere, even if a HMI driver does allow it to be selected. Treat them as read only in the PLC and in the HMI. You should only use Input addresses for real world signals like your wired toggle switch. Only real world signals should execute a write to an Input address.

What you want to get to from your HMI toggle switch is the Output address, but...

Also, as a rule, and even though possible, I would advise against writing directly to PLC Output addresses from a HMI. For you this is probably not so critical, but for more complex programs it is better to assign a unique address specially reserved and named for HMI use. This makes it more amenable to interlocking the signal before reaching its intended target. It also helps to more easily identify external influences in a program.

For HMI related addresses in the PLC you should use internal addresses, such as the default B3 or the N7 Data Files, which can be addressed to the bit level. These addresses are more suitable for reading and writing data or signal status' between the two. An exception to this is that you may read the status of an Input or an Output address directly into the HMI as this is generally non destructive.

Choose an unused B3 address in the PLC. You are probably not using any at present, so B3:0/0 is most likely available?

That's...

File B3, Word 0, Bit 0

I'm assuming you currently have a basic rung with just the Input instruction and the Output instruction?

If you want to keep the functionality of the wired toggle switch in your program then leave the Input instruction and create a parallel branch beneath it. Then add an XIC (Examine if Closed) instruction and address it to B3:0/0. This allows address B3:0/0 execute the same function as the Input address. This is the address you now need to assign to your HMI toggle switch.

I have not used Easy Builder Pro before but I have had a quick look at the AB driver manual...

Where you select the write address for your toggle switch, choose "B3" from the drop down menu instead of "I1".
Then you choose the "Setting" button and the "Address" window allows you to define the B3 address. The address format should be displayed as "DDDdd". "DDD" denotes the Word number and "dd" denotes the Bit number. Because the B3 Data File can be expanded to a maximum of 255 Words, this is why there is 3 "DDD". As each word only contains 16 Bits (0-15) there are only 2 "dd".

So B3:0/0 = 00000
(B3:10/5 = 01005)
(B3:100/15 = 10015)

For this software, the leading zeros for the first part of the address are not necessary, but for subsequent parts they are. So therefore...

B3:0/0 = 000

But the long or short form is acceptable.

Have a go at that and see how you get on?

Regards,
George
 
Last edited:
Hi George,

Glad that you liked the paper. Well, we won't know before hand if there might be any vulnerabilities in the protocol at all. Unfortunately not much research is done on Ethernet/IP at this point of time. If you look into this area of research, people have mostly explored into modbus protocols.

There's no specific way that we approach the attacks with, the attacks are mostly crafted after studying the packet captures and reverse engineering the underlying fields and the data therein. With DNP3 after the initial runs with open source project to generate a traffic, we had a chance to try hands on with real sanitized traffic generated by real equipment. With Ethernet/IP however I just have a PLC, so all we can establish is a communication between a HMI and a PLC, so that I believe narrows down the attacks.

Anyhow, to demonstrate I have a ladder logic that will be working as a traffic signal ( the outputs can really mean anything). I am now using a advance HMI as a interface. I am able to generate a output using the toggle switch in the HMI. So, the trials went well. I'll be experimenting with generating the outputs back on the HMI so that I can mimick a traffic signal. Hope I am able to achieve it.

Thanks! I'll keep you posted.
 
Is your objective to intercept and manipulate packets in transmission or send additional packets to the PLC? I can help you understand the packet structure and workings of Ethernet/IP. I was the one who developed the Ethernet/IP driver for AdvancedHMI, so I have spent countless hours understanding the protocol.

I just will not publicize the vulnerabilities that I am aware of. It goes against my ethics because I have the belief that if the word gets out about a vulnerability, the deviant minds will exploit it much faster than the manufacturer will create a patch for it. In the world of PLCs, not only can an attack do monetary damage, but can potentially have a disastrous affect on worker safety.
 
Hi Archie,

Yes, that would be the objective. Manipulations to energize a wrong output or which was not supposed to go off. Also, manipulations in the communication from the PLC to the HMI so that the master would never know of any wrong operations.

Now, on the protocol, to my understanding all the mischief that's played in the communication is the Command Specific Data Field in the CIP messaging part of the protocol. Should that be the subject to focus if I am manipulating the packet for example to turn on the wrong output? Could you direct me in the right direction in this regard. Also, is there anyway that I can incorporate other CIP services into use to broaden and to have a varied packet captures for analysis!

Thanks Archie!
 
Last edited:
The MicroLogix series controllers use what is referred to as PCCC. The PCCC commands are transported via Ethernet/IP using a service code 0x4B, class 0x67, Instance 0x01. Your focus should be on these PCCC commands. These are covered in detail in the DF1 Protocol and Command Set manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf

Chapter 7 covers the various commands. The one you may be interested in is "protected typed logical write with three address fields", which is command 0x0F, function 0xAA on Page 7-18

Generally the outputs (e.g. O:0/0) are not written to directly by the HMI, instead an internal bit such as B3/0 is more commonly written to and the PLC program will use it to activate an output.
 
Last edited:

Similar Topics

Hi, I cannot find the DLCA1764.EXE utilty software for data retrieving. Can someone share the link to download this software. Thanks!
Replies
4
Views
154
I am currently backing a Micro Logix 1100 and no-one seems to have the file for me to upload from. Is there a way for me to upload the project off...
Replies
15
Views
556
I am trying to set up a read message in a MicroLogix1100 to read the value of a DINT in a ControlLogix5561. I have successfully set up a message...
Replies
2
Views
205
Hello, I have an existing application that has a Powerflex 700 with a 20-COMM-E adapter controlled by a Micrologix 1100 via Ethernet. The setup...
Replies
6
Views
1,205
I have a MicroLogix 1100 and it's capable of ac or dc output voltages. What I don't know is how I'm supposed to tell the 1100 to use dc for the...
Replies
13
Views
1,435
Back
Top Bottom