CyberMonday con ciberseguridad

Las fechas cercanas a Navidad siempre han sido fechas muy importantes para la mayoría de los comercios ya que durante estos días muchos negocios se juegan los resultados de todo el año.

En los últimos años, a las tradicionales compras navideñas, se le han sumado varios días especiales, El Día del Soltero, récord de ventas online en China y otras dos que hemos importado de Estados Unidos: el Black Friday y el Cyber Monday.

El Black Friday y el Cyber Monday son un creciente riesgo de seguridad para las empresas ya que son una oportunidad para que los ciberdelincuentes hagan de las suyas escondidos entre la gran cantidad de tráfico que recibirán los comercios estos días.

Los malos saben que esos días todo el mundo va a estar comprando por internet e intentarán aprovecharse y robar dinero mediante ciberataques de todo tipo.

Pero, ¿Qué tipos de ciberataques podríamos ver ese día? En este post haremos un somero repaso sobre ellos e indicaremos como podemos protegernos de cada uno de ellos.

Phishing

Tal vez uno de los más peligrosos son los ataques de phishing. En un ataque de phishing un ciberdelincuente prepara una página web maliciosa que tiene un aspecto muy similar a nuestro negocio y con un nombre de dominio que sea parecido al nuestro. De esta manera se está aprovechando de nuestra imagen de marca para realizar acciones fraudulentas. A continuación, para dirigir clientes hacia su web realiza una campaña de SPAM comercial con ofertas muy atractivas. Una vez que la víctima ha entrado en su web, si acaba comprando algún producto, el ciberdelincuente acabará recabando los datos de pago de la víctima, momento en el que su página mostrará un error y será redirigido hacia la página del comercio legítimo.

Evitar este tipo de ataques es realmente complejo, pero hay varios métodos para hacerlo más difícil. Por ejemplo las grandes empresas muchas veces adquieren además de su propio nombre de dominio, otros nombres de dominio similares. De esta manera es más difícil que el usuario pique. Sin embargo, mejor que eso es poner un banner en nuestra web informando de que:

• Nuestro negocio no envía SPAM comercial si no estamos apuntados a un boletín.
• Nuestro negocio es seguro y usa HTTPs.
• Nuestro negocio se ajusta a la normativa vigente.
• La transacción comercial se realizará a través de un TPV virtual o el método de pago que utilicemos.

De esta manera al menos una parte de los potenciales clientes estarán informados y es más difícil que “piquen”.

Uso de nuestra imagen de marca

Es una variante del caso anterior. Existe un nombre de dominio similar y un página web similar, pero en este caso, detrás de la web “copiada” hay un negocio y al hacer la compra, el cliente, pensando que ha comprado en nuestra tienda, recibe un producto, generalmente de calidad muy inferior a la que nosotros le enviaríamos.

De nuevo es difícil evitar este problema, pero sí que podemos denunciarlo si lo detectamos.

SPAM comercial

El SPAM comercial en sí puede no ser malicioso, pero si se recibe sin ser solicitado puede convertirse en algo muy molesto y generar una imagen negativa de la marca que “lo envía” (o que aparece como remitente).

Es muy fácil suplantar un negocio y enviar correos electrónicos haciéndose pasar por éste. Si alguien quiere que perdamos imagen de marca, esta puede ser una técnica fácil de llevar a cabo.

Para esta sí que no tenemos solución, ya que es tarea del receptor implantar algún tipo de filtro anti-spam, pero en caso de detección, también es posible denunciarlo a las autoridades.

Ataques de Denegación de Servicio

Este ataque es algo más complejo de realizar. Consiste en enviar hacia nuestra página web tal cantidad de tráfico que nuestros servidores no sean capaces de atenderlo. De esta manera no podrían atender ni las solicitudes del atacante ni las solicitudes del usuario legítimo que accede a nuestra tienda online para realizar sus compras, perdiendo de esta manera un potencial cliente.

Para solucionar este complejo, la mejor solución es subcontratar el servicio de hosting con un Acuerdo de nivel de servicio que nos asegure un 99% de tiempo de alta del servicio. De esta manera será responsabilidad del proveedor el que nuestra tienda esté siempre operativa.

Defacement

Con este nombre se conoce a un tipo de ataque sobre nuestra página web en el que los datos de clientes no se ven afectados, pero sí el aspecto de la página web, apareciendo la página web con información falsa, jocosa o de cualquier otro tipo, que a fin de cuentas supone un fuerte impacto sobre nuestra imagen de marca.

Para conseguirlo los ciberdelincuentes habran seguido alguno de los siguientes caminos:

• Habran robado la contraseña de acceso al panel de gestión de nuestra web por haber utilizado contraseña por defecto o fácilmente deducible.
• Utilizado alguna vulnerabilidad en nuestro gestor de contenidos web.
• Utilizado un troyano o algún otro tipo de malware para conseguir o bien las contraseñas o bien tomar el control del sistema y a través de él modificar la página web.

Para evitar este tipo de ataques es necesario:

• Utilizar contraseñas robustas para acceder al gestor de contenidos web.
• Mantener siempre actualizado el gestor de contenidos web.
• Mantener siempre actualizado todo el software de la empresa.
• Tiene siempre instalado y actualizado software antivirus en todos los sistemas de la empresa.

Robo de datos de clientes

Tal vez uno de los riesgos más importantes que afronta una empresa que tenga presencia y venta online.

La información de los clientes debe ser sagrada, máxime si se trata de información de pago. Si esta información se almacena en algún fichero, éste debe seguir estar inscrito en el registro de ficheros de AGPD y se debe cumplir con la LOPD a rajatabla.

Las formas en que un ciberdelincuente puede acceder a este fichero son las mismas que en el caso anterior:

• Robando contraseñas.
• Aprovechándose de vulnerabilidades en el software que utilizamos.
• Utilizando un troyano en nuestros sistemas.

O una combinación de ellas. Por esta razón las formas de evitarlo son las mismas que antes:

• Utilizar contraseñas robustas.
• Mantener actualizado todo el software.
• Concienciar al personal.

No hay que olvidar que los ciberdelincuentes tienen muchas formas de obtener beneficio de toda la información que roben de nuestros sistemas.

Click Fraud y Black SEO

Son variantes de los casos anteriores. En ellos, el ciberdelincuente no modifica de una forma visible nuestra página web. Lo hace de una forma invisible con el objetivo final de obtener algún beneficio económico.

Las modificaciones que se realizan van desde añadir código a la página web de manera que al visitarla la página está “haciendo clic” sobre anuncios online sin realmente visitarlos (aumentando así el número de visitas de una web, su posicionamiento web y recibiendo dinero por los clics realizados procedentes de anuncios ocultos). A esto se le conoce como Click Fraud.

Por otra parte, si el atacante quiere mejorar su posicionamiento en Google, puede hacerlo de una forma ilegítima (Black SEO) y utilizar nuestra web para añadir enlaces (ocultos) a la misma, de manera que Google considere su web más “interesante” para las búsquedas de los usuarios.

Estos ataques por sí solos no son peligrosos ni para los usuarios ni para la empresa, pero una vez descubiertos suponen una pérdida de confianza por parte de los clientes, puesto que no suelen venir solos y si el ciberdelincuente ha podido utilizar nuestra web para realizar Click Fraud, la habrá podido utilizar también para robar datos de tarjetas y demás.

La forma de evitar esto tipos de ataques son las mismas en los casos anteriores, actualizar, actualizar y actualizar y concienciar y concienciar.

Que no nos cojan con las defensas bajas

Estar posicionados en Internet es absolutamente imprescindible hoy en día, y además con periodos como el navideño o el fin de semana del Black Friday, más. Pero no hay que olvidar que en Internet se esconden oscuros personajes ante los cuales debemos defendernos.

En periodos de gran cantidad de tráfico web como estos, se nos puede colar uno de estos personajes, modificarnos la web y hacernos mucho daño. A nosotros y a nuestra imagen. Por eso es necesario conocer las amenazas que nos acechan y defendernos ante ellas.

Asi que recordad. ¡Que no nos cojan con las defensas bajas! ¡Y buen Black Friday!

Design and implementation of a honeynet for an ICS environment (Part 2/2)

I a previous post we introduced what a Honeypot and honeynet were, and the different types of honeypots. The different implantation phases were also discussed. In this post we'll talk about the different open honeynet solutions available.

Open Honeynet solutions

A list of open honeynet solution is discussed next:

Modern Honey Network (MHN)

This is a tool for easily creating honeynet in a visual way. It allows the creation of high and low interaction deployments. It has a REST API to send information to external services. One of the cons of this tool is the number of false positives that show.

URL: https://github.com/threatstream/mhn

Dockpot

Dockpot is a honeypot system defined by SSH. Basically is a NAT device with capacity to act as a SSH proxy between the attacker and the honeypot itself, performing monitorign and logging tasks of the network activities that occur against the honeypot. One of the characteristicas of this tool is that dockpot runs the honeypot system (using docker technology) when it detects a new connection, and destroys the container when it detects there are no connections against the system. This allows to mount a high interaction network and no longer have to worry about the machines.

URL: https://github.com/docker/global-hack-day-3/tree/master/dockpot

Conpot

Conpot is a low-interation honeypot server focused on industrial control. It has capabilities to operate as a honeypot of both types, low and high interaction. It's designed to be easy to implement, modify and extend. By providing a range of common OT protocols, this system has the bases to emulate complex infrastructures, capable of convincing an adversary that he has in his hands a large industrial complex. To improve the ability to mislead, it also provides the possibility of a HMI server to increase surface honeypots attack.

This is OK for a first pilot. It's one of the tools that currently have a more active community.

As a low interaction honeypot, by default Conpot simulates to be an S7-200 device, although it has configuration parameters to simulate practically any device. As a high-interaction honeypot, Conpot can be used as a gateway to a physical device, so the attacker actually accesses this device, making it difficult to detect the honeypot itself.

URL: https://github.com/mushorg/conpot

Honeytokens

Honeytokens are artificial elements that emulate data which are deliberately placed in a real resource or system in order to detect unauthorized attempts to use this information. Honeytokens are characterized by properties that make them look like data. These elements must be accessible to potential attackers who intend to violate the security of an organization in an attempt to extract information in a malicious manner. One of the main challenges in honeytokens generation is the creation of data that simulate real values ​​and are difficult to distinguish from false data. At this point it is recommended to follow the guidelines for the generation of an automatic value generation system. As an initial phase in the creation of a HoneyNet, we can use Open Canary to perform a series of tests provided they are not under OT protocols.

URL: https://github.com/thinkst/opencanary

GNS3

GNS3 is a graphical network simulator that allows to design complex network topologies and start simulations about them. This type of tools are very useful to be able to deploy and modify the different topologies of the honeynet network. GNS3 should be combined with this series of applications in order to obtain the expected performance in the project at hand:

• Dynamips, an IOS emulator that allows users execute binary images of Cisco Systems.
• Dynagen, a text front-end for Dynamips
• Qemu and VirtualBox, that allow to use virtual machines as a PIX firewall.
• VPCS, a PC emulator with basic networking functions
• IOU (IOS on Unix), special compilations of IOS provided by Cisco to run directly on UNIX Systems.

GNS3 is an excellent complementary tool to real labs for Cisco network administrators or people who want to pass their CCNA, CCNP, CCIE DAC or certifications.

URL: https://www.gns3.com/

Gridpot

honeypot for the electrical sector, uses conpot for its deployment, the specification has been added to have communications using the IEC 61850 protocol.

URL: https://github.com/sk4ld/gridpot

ScadaHoneynet

It's a software-based framework to simulate a variety of industrial networks such as SCADA, DCS, and PLC architectures. With this tool a single Linux host can simulate multiple industrial devices and complex network topologies. Given the variety of deployments and the lack of standard, well-defined architectures for industrial networks, it attempts to create the building blocks so that users can simulate their own networks.

URL: scadahoneynet.sourceforge.net

GasPot

GasPot is a honeypot that has been designed to simulate an AST Veeder Root Gaurdian.

These tank meters are common in the oil and gas industry for gas station tanks to assist with the fuel inventory. GasPot has been designed to generate different series of values in each use, which allows to make it more invisible to the experience of the attacker simulating with more precision a real system.

URL: https://github.com/sjhilt/GasPot

HoneyComb

System that automatically generates signatures for NIDS Systems. The system applies protocol analysis techniques and the detection pattern of captured traffic in trap systems. The use of traffic within the honeypot has the advantage of concentrating the traffic that in our opinion would be considered malicious by definition. The idea would be to be able to do something similar in the part exposed to the services subcontracted like System of intelligence.

The system is an extension of the trap system honeyd, it is specified for the inspection of the traffic inside the honeypot; Currently the system works by examining protocol headers as well as payload data. The integration of this system with honeyd has several advantages over an external probe approach, directly placed at the network level; It avoids duplication of effort, as it uses libpcap to capture relevant packets, it avoids common cold boot problems such as NIDSs, as it is integrated in the honeyd not only passively listens to traffic, but emulates consistent responses to respond to incoming requests. (Not for OT protocols, or so I think), with this mechanism we can determine exactly when a new connection is started or terminated.

URL: http://www.icir.org/christian/honeycomb/

IOThoneypot

python telnet server trying to act as a honeypot for IoT Malware which spreads over horribly insecure default passwords on telnet servers on the internet

URL: https://www.usenix.org/system/files/conference/woot15/woot15-paper-pa.pdf

PlanetLab

Set of distributed servers through the academic networks of the world. Forming a computational laboratory on a planetary scale, allowing to develop, install and execute applications in a test environment deployed over the network with real world conditions.

It Provides a platform for researchers to experiment with network services on a global scale with real workloads, being able to withstand short or long duration experiments, being able to execute at the same time in isolation and not to affect each other. What we are trying to achieve is to catalyze the evolution of the Internet towards a service-oriented architecture.

URL: https://www.planet-lab.org/

Design and implementation of a honeynet for an ICS environment (Part 1/2)

Industrial Control Systems (ICS) are becoming attack objectives more a more often. This is caused mainly because of the impact that the compromise of an ICS can cause. At the same time, these systems have a very long lifetime and initially were not designed with security in mind.

Traditionally, ICS systems are not bound to the IT world and use their own (sometimes proprietary) protocols different from th IT standards. For these reasons it's not really well-known how to exploit these systems and what the implications of and exploitation mean. A good way to know the attack vectors and attackers objectives is to use honeypots to obtain the maximum information about the movements these attackers perform during the attack phase.

Honeypots and Honeynets

A honeypot, or trap system, is a software or combination of systems whose intention is to attract attackers, simulating to be vulnerable or weak systems. It's a computer tool used to gather information about the attackers and their techniques. Honeypots can distract attackers from the most critical systems, and quickly warn the system administrator of an attack attempt, appart from allowing a deep attack & attackers examination, during and after the attack to the honeypot system.

A Honeynet is a special type of honeypot. It's a high interaction honeypot that act over a whole network, designed to be attacked and therefore recover mauch more information about the possible attackers. In a honeynet real systems are used with real operative systems and running real application. This type of noneypots are mainly used for researching of new attack techniques and therefore testing the modus-operandi of intruders.

What are honeynets for in an ICS environment?

Presently is difficult to reproduce a standard SCADA network, given that there is a hugh variety of different industrial network deployments. This is caused by the heterogeneous nature of industrial sectors and by a lack of standard architectures for each of these specific sectors. One of the main reasons why control network emulation becomes very hard to implement is difficulty to simulate communication networks, due to the fact that there are many different and complex networks and network topologies.

As a honeynet is a dynamic environment, this allows the quick modification of the honeynet infrastructure to adapt it to different environments or industrial sectors. Critical data acquisition obtained from the possible attacks reeived by the honeynet will allow the development of mechanisms, tools and procedures to mitigate these attacks in a near future or recover in a most effective way.

Honeynet development phases

To develope a honeynet there are a number of phases that need to be followed:

• Phase 0: Project initial phase. In this phase a set of different systems are connected directly to internet. These systems will only collect attack attempts, ports, services, IPs, etc.
• Phase 1: In this phase, different devices inside the honeynet network will interact among them. Starting from the data acquired in phase 0, a network infrastructure will be formed following the attack preferences found in phase 0. In this phase the software applications will be deployed in the different systems in order to run their own roles inside the honeynet. In this phase there will be a more thorough process of information gathering and willl focus in media and methods used during the attacks.
• Fase 2: research phase and honeynet dynamic changes. Starting with the data obtained in phase 1, different elements from the honeynet will be modified to improve the network infrastructure and the securization process. In this phase first reports will be obtained and printed.

Glossary

Low interaction honeypot

A Low interaction honeypot simulates some services to detect directed attacks to those services. Depending on the quality of simulation, these honeypots will obtain more or less information. This type of honeypots are mainly used to detect attack attampts and protect a network infrastructure.

High interaction honeynet

High interaction honeypots are used to be able to analyze in depth the previously detected attacks. To obtain as much information as possible to be as close to reality as possible, real devices are used, from which all possible information is extracted about the different attacks they receive.

When talking about ICS, devices like PLCs, RTUs, IEDs, etc, do not generally have enough computing power to include them in the information gathering process. For this reason a better alternative is to use a gateway system, that will relay connections to ICS device and that will extract all the attack data and will send them to a centralized server which will be the responsible for the analysis in depth.

Available tools

In the next post, some freely available tools like the following will be discussed:

• Modern Honey Network (MHN)
• Conpot
• Honeytokens
• Gridpot
• ScadaHoneynet
• GasPot
• HoneyComb
• IOThoneypot
• PlanetLab

Recount of Internet-accessible PLCs from Shodan

This recount was done on February 2017 by searching only in Shodan. Of course we could not look for all ICS device vendors nor all products, there are many many left (Moxa, Hirschmann, Westermo, Digi...) but tried to look for the most widespread vendors and devices. However, this table will be updated as soon as I look for other vendors.

In the table, we show the vendor, the family, the specific product(device) and the search term used in shodan. The last column is the number of devices found of that type.

Vendor	Product family	Product	Shodan Search term	# Devices found
Siemens	S7-200 family		port:102 & S7-200	105
		S7-200	port:102 & !S7-200 & 151-	176
			Total(S7-200)	281
	S7-300 family	S7 312	CPU 312 & port:102	0
			!CPU & port:102 & 312-	9
		S7-313	CPU 313 & port:102	254
			!CPU & port:102 & 313-	24
		S7-314	CPU 314 & port:102	210
			!CPU & port:102 & 314-	40
		S7-315	CPU 315 & port:102	450
			!CPU & port:102 & 315-	104
		S7-316	CPU 315 & port:102	0
			!CPU & port:102 & 315-	5
		S7-317	CPU 317 & port:102	60
			!CPU & port:102 & 317-	4
		S7-318	CPU 318 & port:102	103
			!CPU & port:102 & 318-	6
		S7-319	CPU 319 & port:102	35
			!CPU & port:102 & 319-	0
			Total (Series 300):	1319
	S7-400 family	S7-412	!CPU & port:102 & 412-	8
		S7-414	!CPU & port:102 & 414-	7
			Total (Series 400):	15
	S7-1200 family
		S7-1211	!CPU & port:102 & 211	25
		S7-1212	!CPU & port:102 & 212	236
		S7-1214	!CPU & port:102 & 214	544
		S7-1215	!CPU & port:102 & 215	58
		S7-1217	!CPU & port:102 & 217	1
			Total (S7-1200)	864
Schneider Electric	Modicon Family M-221
		TM221CE24T	TM221CE24T	28
		TM221CE24R	TM221CE24R	15
		TM221CE16T	TM221CE16T	35
		TM221CE16R	TM221CE16R	25
		TM221ME16R	TM221ME16R	46
		TM221ME32TK	TM221ME32TK	13
		TM221CE40T	TM221CE40T	112
		TM221CE40R	TM221CE40R	68
			Total (M-221):	342
	M-241
		TM241CEC24R	TM241CEC24R	3
		TM241CE24R	TM241CE24R	8
		TM241CE24T_U	TM241CE24T_U	14
		TM241CEC24T_U	TM241CEC24T_U	27
		TM241CE40R	TM241CE40R	17
		TM241CE40T_U	TM241CE40T_U	18
			Total (M-241):	87
	M-251
		TM251MESC	TM251MESC	3
		TM251MESE	TM251MESE	23
			Total (M-241):	26
	M-258
		TM258LF42DR	TM258LF42DR 1	1
	M-340		port:502 & BMX P34
		BMX P34 2020		587
		BMX NOE 0100		280
		BMX NOE 0110		10
		BMX P3420302		45
		BMX P342030		6
		BMX P341000		2
		BMX PRA0100		3
		BMX NOR 0200		1
			Total (M-340)	934
	M-580		port 502 & BME P58 5	5
	TSX Premium Family		port 502 & !BMX !BME TSX	109
			port 502 & !BMX !BME !TSX & TSXETY4103	65
			Total (TSX Premium): 174	174
	Modicon Momentum
		CBU 98090	CBU 98090	32
		CBU 98091	CBU 98091	6
			Total (Momentum): 38	38
Allen Bradley	CompactLogix	CompactLogix 1769	port:44818 & rockwell & 1769	1339
Rockwell		CompactLogix 1756	port:44818 & rockwell & 1756	222
		CompactLogix 1747	port:44818 & rockwell & 1747	182
		CompactLogix 1761	port:44818 & rockwell & 1761	129
		CompactLogix 1768	port:44818 & rockwell & 1761	39
	Micro Family			2531
	Other			1041
			Total (Allen Bradley)	5483
Phoenix Contact	ILC
		ILC 171	port:1962 ILC 171	19
		ILC 150	port:1962 ILC 150	112
		ILC 151	port:1962 ILC 151	191
		ILC 191	port:1962 ILC 191	20
		ILC 130		26
		ILC 131	port:1962 ILC 131	35
		ILC 170	port:1962 ILC 170	9
		ILC 190	port:1962 ILC 190	5
		ILC 330	port:1962 ILC 330	7
		ILC 170		9
		ILC 370		5
		ILC 350		6
			Total (Phoenix Contact)	444
Invensys			Invensys
			Total (Invensys)	61
ABB	ABB Stotz
		ABB Stotz Kontakt 33	ABB Stotz Kontakt 33	4
		ABB 33	!Stotz port:"502"	14
		ABB Stotz Kontakt 29	ABB Stotz Kontakt 29	18
		ABB 29	!Stotz port:"502"	4
		ABB Stotz Kontakt 34	ABB Stotz Kontakt 34	30
		ABB 34	!Stotz port:"502"	8
		ABB Stotz Kontakt 37	ABB Stotz Kontakt 37	34
		ABB 37	!Stotz port:"502"	34
			ABB 43	1
			Total (ABB)	146
Delta-V
			Total (Delta-V)	21
Wago			wago port:"44818"	38
			wago & snmp	35
		Wago 750-880	wago 750-880	18
		Wago 750-881	Wago 750-881	36
		Wago 750-873	Wago 750-873	10
		Wago 750-841	Wago 750-841	8
		Wago 750-341	Wago 750-341	1
			Total (Wago)	73
Opto-22
Beckhoff			beckhoff & port:4840	4
			Total (Beckhoff)	4
Lantronix
		Lantronix UDS1100	Lantronix UDS1100	2763
		Lantronix UDS2100	Lantronix UDS2100	265
		Lantronix SLS	Lantronix SLS	1592
		Lantronix SLSLP	Lantronix SLSLP	272
		Lantronix xDirect 232	Lantronix xDirect 232	1126
		Lantronix MSS100	Lantronix MSS100	150
		Other	Lantronix	19738
			Total (Lantronix)	24013
Omron			omron & port:44818	296
			port:9600 & cj2m	395
			Total (Omron)	691
Yokogawa			yokogawa & port:44818
			Total (Yokogawa)	9
General Electric			port:18245,18246 product:"general electric"
			Total (GE)	51
Honeypots
			Conpot	61

The Unity (UMAS) protocol (Part V)

This is the fourth article of a series of entries in this blog about the Unity protocol, used by Schneider Electric devices for configuration purposes.

INDEX

Part I. Introduction, initialization phase, functions codes used in the initialization phase

Part II. Function codes used to read and write memory values from/to memory

Part III. Function codes used to deal with logic programs, and work with the PLC

Part IV. Other extra function codes

Part V. Modicon Premium PLCs specific function codes

In this part we'll talk about specific function codes for Schneider Electric's Modicon Premium PLCs.

---

Only for Schneider Premium Modicon PLCs there are a number of function codes. For instance:

Read IO Object (“01 70”) and Read IO Module ("01 73")

These function codes allow Unity to read the Discrete Premium I/O Modules (More information on them in this link. These modules can be read normally, for status or when an error occurs in the module.

Normal requests

To be able to read an IO module, first you need to put it in "read status". To do that a "01 73" request need to be sent. This is the structure of that request:

• NMOD is generally 4 or 8, depending on the size of the IO Module. If NMOD is 4, next 2 WORDs (4 bytes) indicate which module we are referring. If NMOD is 8, next 4 Words (8 bytes) indicate the IO Module number & Offset. Therefore the NMOD field is kind of a length field for the IO Module Offset.
• WORD 0, WORD 1, WORD 2, WORD 3. Indicate the Premium IO Module number & Offset.

Response

In the response the first byte can be value from 0 to 4. The last two bits in this byte have this meaning:

• Last bit: Module Present (True/False)
• 7th bit: Module configured (True/False)

Next 4 bytes received store the Module Identity, and next 4 bytes are useless.

9th byte indicates the module version, and 10th byte indicates LEDs states.

Read IO Object

An IO Object is a value inside an IO Module. Function Code 0x70 allows Unity to read IO Module Objects. To be able to read these object, first, the module need to be set as "read". To do that a 0x73 request like the previously seen need to be sent prior to sending a 0x70 request.

An IO Object can be read normally, for status or for an module in error. The normal request structure is the following:

In this request the field in blue is the "Channel" and the second Word of the orange field is the "IO Object". A FF value means "all".

When the request is done to read the IO Object status, the request is the following:

Green field can have the values:

• 01 10: When a channel exchange for an IO Object is requested.
• 01 40: When an IO Object is read "For explicit".

And finally when the request is for a module in error the request is the following:

Response

The response for a 0x70 request indicate the input Number, Output Number, State and Structure of the module. If the request was made "For status" only the status of the module is returned.

Write IO Object (“01 71”)

The structure of a IO Object write request is the following:

---

Read Ethernet Master Data(“01 39”)

Clients running Unity can access or download applications to devices on distributed control systems. The ethernet Master Data is the network configuration information for distributed control systems. It can be read, in Schneider Modicon premium device with request "01 39".

The "Read Ethernet Master Data" request has the following structure:

Response

• First six bytes of the response have an unknown meaning.
• Seventh byte is 0x22 (unless an error in device).
• Next 4 bytes are the 4 bytes of the device's IP Address.
• Next 4 bytes are the 4 bytes of the device's Network Mask.
• Next 4 bytes are the 4 bytes of the device's default gateway.

In the next entry the last function codes found of this protocol will be explained.

The Unity (UMAS) protocol (Part IV)

This is the fourth article of a series of entries in this blog about the Unity protocol, used by Schneider Electric devices for configuration purposes.

INDEX

Part I. Introduction, initialization phase, functions codes used in the initialization phase

Part II. Function codes used to read and write memory values from/to memory

Part III. Function codes used to deal with logic programs, and work with the PLC

Part IV. Other extra function codes

Part V. Modicon Premium PLCs specific function codes

---

In this part we'll talk about several very heterogeneous requests. We'll talk how to start and stop PLCs, how to check connections, how to monitor variables, etc.

Start and stop the PLC (“01 40” and “01 41”)

The message “01 40 FF 00” (again with the initial "01" byte only for firmware versions previous to v2.7) will start the PLC and run the currently internally stored program. The PLC will reply with “01 FE” if everything worked fine or “01 FD ” if any error occurred.

For instance if the response is:

00 FD 81 80 80 51 12 00 04 00 00 00

That means that the PLC is currently reserved by other IP. However I've not been able to decode these bytes.

The message “01 41 FF 00” will stop the PLC if it's currently in RUN state. The PLC will reply with “01 FE” if everything worked fine or “01 FD ” if any error occurred.

---

Check PLC connection status / Connect with Diag Buffer (“00 58”)

When the Unity connects to the PLC in monitoring mode, it keeps sending regularly this kind of messages.We still don't understand them very well. There are four kinds of message (four monitoring submessages):

1. "00 58 01" message can be used to log on the "Diag Buffer". For instance, before starting the strategy upload/download process a request like the following is sent from Unity Pro:
   

   The message structure is the following:

   

   Let's explain this (as per a piece of internal code found). After umas code "00 58", and subcode "01", 4 bytes are hardcoded to "00". Next two byte are still unknown to me and the last two "00" byte are kind of indicator that the message ends here.

   So far, the responses from the PLC have always been “00 FE 01 00”, that is, an OK response. This "01 00" seems to be something called "N_MMI".

   I tried to modify this request and only found that, if modifying some bytes, the response changes to “00 FE 02 00”. I don't understand why.
   

2. "00 58 02" requests are used to logout from the "DiagBuffer". In this case the message structure is:
   

   Let's see an example:

   

   In this case, the response is always "00 FE" (OK).

   
   
3. "00 58 03" is used to Ack an error with the Diag Buffer. In this case the message structure is the following:
   

   After the "00 58 03" code and subcode, next two bytes are the N_MMI value and the next two bytes are the error code returned by a "00 58 07" request.

   Unfortunately I don't have any screenshot for this request/response.

   
   
4. "00 58 07" is used to query the Diag Buffer for information. This is the message structure:
   

   As it can be seen, after the "00 58 07" code and subcode, next two bytes are the N_MMI obtained during "00 58 01" request, 4 "00" hardcoded bytes come next followed by the "Diag value" requested. This is an exmple requesting Diag Value "FB 00":

   

   In this case the reply was “00 FE 00 01 02 00”, which is an OK response or "00 FD" and a bunch of bytes showing the errors found in the PLC. Unfortunatley I still have not been able to decode the different Diag values that could be retrieved.

---

“Copy” me this info (or “Reply me with a copy of this info”)

The “00 0A” request is a “repeat“ command. It resends back the bytes that we send to him. This behaviour could be used by malicious attackers to commit DDoS or to fake an attack sender.

This is an example of request:

...and its response:

---

“Monitor” (aka read/write) system bits and words ("01 15 50")

In the Part II of this tutorial we saw that requests “00 22” and “00 23” allowed us to read and write system bits and words.

There is another way (using “01 15 50” requests) to read and write System bits and words. However it's a longer and trickier process.

Reading System bits

With this method, to read the value of a System bit, we need to send two requests and get the response to the second request.

First we need to tell the PLC that we are going to monitor the value of a System bit. This is done with the following request:

This request has the following structure:

header: 01 50 15 00 03 01 
read: 01 00
length: 00 0d
action: 00 03 01 00 (reading a value)
code: 00 0c 00 15 
system bit: 01 00 2a 00
system bit to read +4 (little endian): 3F 00 00 00 (it's the system bit 59 - 3A + 4)
unknown: 0c 00
unknown2: 01 05 01 04 
last4 bytes: 00 00 00 01 (always 1).

This request will tell the PLC we are going to monitor system bit 59. Now we'll have one (the SB59) monitored System bit.

Now we will send a message to ask the value of all monitored system bits (in this case, only one):

This message is ALWAYS the same, it doesn't ever change. However we don't understand the meaning of every byte:

01 50 15 00 02 09 01 0c 00 01 00 07

However it means something like: “send me the vaues of the monitored variables”.

The response to this message is what we are looking for:

And the bit with the value of the system bit is the one before the “07” byte. If that bit is 0, the system bit is 0, if it's 1, the system bit will be “1”.

Note that it is possible to monitor more than one system bit. It is even possible to monitor at the same time system bits, system words, inputs/outputs and variables. However, the messages become much trickier, so we will explain them one-by-one.

Writing system bits

In a similar way we can write system bits with a message with following structure:

header: 01 50 15 00 03 01 (always the same)
write: 02 0d
length: 00 0d
action: 00 03 02 00 (writing a value)
code: 00 0d 00 14
system bit: 01 00 2a 00
system bit to read +4 (little endian): 52 00 00 00 (it's the system bit 78 - 4E + 4)
unknown: 0c 00 01
system bit value to write: 01 (for a 1) or 00 (for a 0)
unknown2: 05 01 04 
last4 bytes: 00 00 00 04

So, the full request to write a “1” in system bit 78 is:

01 50 15 00 03 01 02 0d 00 0d 00 03 02 00  00 0d 00 14 01 00 2a 00 52 00 00 00 0c 00 01 01 05 01 04 00 00 00 04

Reading System words

In this case the message is similar to:

01501500 0301 0377030e 00030300 000c0015 02002b00 04010000 0c0001    05010400000003 

header: 01 50 15 00 03 01 (always the same)
unknown (possibly a variable value):  0377030e
action: 00 03 03 00 (reading a system word)
code: 00 0c 00 15
system word: 02 00 2b 00
system word to read  (little endian): 04 01 00 00 (0104 corresponds to system word 5Ah -90d-  5Ah+5Ah+50h=0104)
unknown: 0c 00 01
system bit value to write: 01 (for a 1) or 00 (for a 0)
unknown2: 05 01 04 
last 4 bytes: 00 00 00 03

With this message we start monitoring System word 90.

Now we need to send a message to get the value of all monitoried System Words. This message is ALWAYS the same, it doesn't ever change:

01 50 15 00 02 09 01 0c 00 02 00 07

The only difference with this message for System bits is the byte with value “02”. Previously the value was “01”.

So, the response to this message is:

0cfe 09 02 00 fa 00 07 00 00 02 00 00 00 <-- The value what was written was 250 ("fa")

This is the meaning of every field:

Header --> 0cfe (which os an “OK”)
Action --> 09 02 00 (Response to a reading)
Value --> fa 00 (It's a 16 bit value. 250d in this case)
Unknown --> “07 00 00 02 00 00 00”

Writing System words

This is an example of a system word modification using the monitoring technique:

The message has the following structure:

header + action: 01 50 15 00 04 01 
unknown (possibly a variable value):  020e000e
action: 00 03 02 00 (writing a system word)
code: 00 0e 00 14
system word: 02 00 2b 00
system word to write  (little endian): b8 00 00 00 (corresponds to system word 52d-  34h+34h+50h=b8h)
unknown: 0c 00 01
system bit value to write: 0d (in this case is a 13d value)
unknown2: 05 01 04 
last 4 bytes: 00 00 00 02

The last 7 bytes are repeated twice.

And this is all for today. In the following part we'll talk other straneous function codes found that have an pseudo-unknown meaning.

The Unity (UMAS) protocol (Part III)

This is the third part of a series of articles describing the Unity (UMAS) protocol used to configure Schneider Elctric industrial devices. It's a Schneider-Electric proprietary protocol used to configure Modicon PLCs and t's been obtained through a reverse-engineering process:

INDEX

Part I. Introduction, initialization phase, functions codes used in the initialization phase

Part II. Function codes used to read and write memory values from/to memory

Part III. Function codes used to deal with logic programs, and work with the PLC

Part IV. Other extra function codes

Part V. Modicon Premium PLCs specific function codes

---

In this part we'll talk about Unity requests regarding PLC logic(programs) upload and download process. In this entry I will talk about the logic or program running in a PLC as the

Initialize and finish a logic/program upload (“01 30” and “01 32”)

b>Important note:After upgrading to firmware version 2.7, the first byte (always was "01") varies. To know which is the value of this byte, please check request "01 04" on part I of this tutorial. In this tutorial I will keep writing this "01" byte in all examples, but that byte doesn't need to be there.

A program upload (computer --> PLC) process comprises three types of messages. The first message tells the PLC that an upload process is going to start. It's a single request (“01 30 00 01”) with no information in it:

It just informs the PLC that a program upload comes next. After this message is sent, Unity starts uploading “blocks” of data to the PLC. This is done with messages “01 31” that will be explained in next section. When last “block” is uploaded, a message “01 32” is sent to the PLC, notifying that the program upload (Computer --> PLC) process have ended in “N” data blocks.

Upload a binary block of the strategy (“01 31”)

The structure of an upload block message is the following:

Let's explain that:

• UMAS code (“01 31”).
• “00 01”. Always.
• 2 bytes with the block number that's going to be written in Little Endian mode, starting with “01 00”.
• 2 bytes with the block length. Little endian. In the following example this field has a “DA 00” value which means 218 bytes little endian. If we try to trick this and send more than 218 bytes (in this case), only the first 218 will be written in the PLC, if less bytes are sent an error message (“00 FD”) will be received.
• The 218 (or whatever) bytes. The maximum block size is negotiated previously in the “00 01” message (See part I of this tutorial).

When a program is downloaded or uploaded from/to a PLC, the data needs to have a specific structure. When from Unity Pro a program is saved to disk, it creates a zip-like file with a ".APX" file with exactly the same hexadecimal structure of the data sent to the PLC. That's why I call the structure of the data sent to the PLC as "APX file". This structure will be explained later in section VI of this tutorial.

For this reason, the data which is sent to the PLC can be read from a valid APX file. You can get one by downloading a strategy from the PLC or just unzipping a Unity STU project. The APX file has many integrity check all along the file. Therefore only a few bytes of the file can be modified.

The upload (computer to PLC) process is quite tricky. The first blocks sent to the PLC must have a specific length:

• Block 1 → 64 bytes (with the first 64 bytes of the APX file)
• Block 2 → 264 bytes (with bytes 65 to 328 of the APX file)
• Block 3 → 64 bytes (with bytes 329 to 373 of the APX file)
• Block 4 → 1014 bytes (if possible)
• Block 5 → 998 bytes (if possible)
• Block 6 → 1008 bytes (if possible)
• Block 7 → 1014 bytes (if possible)

After the 7th block, all blocks are 1022 bytes long (if possible, it depends on negotiation performed during connection. Have a look to sections I and VI for more information). In blocks 4 to 7, if the max packet size is lower than 998, they will be sent with the max packet size.

After many tests I realized that, the strategy upload process:

• need to be done with a minimum message rate
• need to be done in the appropiate order (starting with block 1, then block 2…)
• need to be preceded by the read of blocks 13h and 14h. This will be explained later on section VI
• if we add extra bytes at the end of the last block (until a max length of 1014 bytes), they will be stored in the PLC, however they will never be restored back when downloading, as during the download process is the PLC who decides the number of bytes to send.
• If the APX has suffered any modification, it will send back an error message.

Initialize and finish a strategy download (“01 33” and “01 35”)

The program-download (PLC to Computer) request is quite similar to the program-upload request ("01 30"). There are two messages that notify the start (“01 33”) and the end (“01 35”) of the download process.

Note that in this case (and the next one) the PLC was using a firmware version over (or equals to) 2.7 and the requests do NOT start with "01" but with a "random" number. This will be explained later.

The start-strategy-download message (“01 33”) will send the PLC the maximum packet size expected (In the following example "FD 03" in Little-Endian format, which means 1022 byts). The PLC's reply will be OK (“01 FE”) or Error (“01 FD ”).

The end-of-program-download message ("01 35") will check with the PLC the number of blocks received:

In this case informs that “55 00” - Little endian- blocks were sent, which mean 85 blocks. This is therefore the "01 35" request structure:

Download a binary block of the program(“01 34”)

After sending the start-of-program-download message (“01 33”), the strategy is requested block-by-block, starting with block 1, and ending when no data left is sent.

Let's see a real example. In the following example we are requesting block 07 (note the last two bytes of the request: “07 00”).

The response from the PLC is the block 7 of the program memory. In this case 1014 bytes long:

This process is repeated until no data is sent back. Note that the block 1 is always requested twice.

The data recovered (after the first 7 bytes) is appended to the APX file. When the process finishes this file stores the whole strategy, variables and other important information for Unity software.

Therefore the upload process (Computer to PLC) comprises the following requests:

1. 01 30
2. 01 31 + data
3. 01 31 + data
4. ...
5. 01 31 + data
6. 01 32

While the download process is done by sending the following requests and expecting the returned data:

1. 01 33
2. 01 34
3. data is returned
4. 01 34
5. data is returned
6. ...
7. 01 34
8. 01 35

Create, restore and remove a backup of the strategy in the Internal Memory card (“01 36”)

Although this requests is not part of the program upload or download proceses it's been added in this section because it's related with how the program is stored in the PLC.

The program is stored in the PLC memory, however it can also be stored, as a backup, in the external SD card included in the PLC. The process of storing, restoring and verifying the program storage can be performed with the "01 36" requests.

There are four "01 36" subrequests:

• Message “01 36 01 00 00” will make a copy of the running strategy into the internal SD card
• Message “01 36 02 00 00” will restore a previously stored backup from the SD card to the PLC program memory
• Message “01 36 03 00 00” will compare the backup stored in the SD with the startegy that's currently running in the PLC
• Message “01 36 04 00 00” will remove the backup currently stored in the SD card.

The messages are very simple (just the bytes shown en the previous four bullets). The response is either "01 FE" for OK or "01 FD" when an error occurs:

And this is all for today. In the following part we'll talk about function codes used to monitor System bits/words and variables, and about Diagnostic funcions.

The Unity (UMAS) protocol (Part II)

This is the second part of a series of entries that explain the configuration protocol used by Schneider-Electric devices, an mainly PLCs (Programmable Logic Controllers) in order to be configured. This is a proprietary protocol based on the well-known Modbus Protocol.

INDEX

Part I. Introduction, initialization phase, functions codes used in the initialization phase

Part II. Function codes used to read and write memory values from/to memory

Part III. Function codes used to deal with logic programs, and work with the PLC

Part IV. Other extra function codes

Part V. Modicon Premium PLCs specific function codes

---

UMAS Function Code 0x20 - MEMORY BLOCK READ

This is a very important Function Code. It allows a client to read a specific offset from a memory block of the PLC device.

The request format is the following:

The PDU starts with the UMAS function code 00 20, the third byte meaning is unknown, sometimes its value is “00”, sometimes is “01”.

Next 16-bit value reference the block number, in this case “00 13”. Little Endian.

Next 16 bits are the starting offset. In the first request is “00 00”, in the following is the sum of the previous request offset plus the previous request' requested bytes. Little Endian.

Next 16 bits are unknown but they are always “00 00”. Always.

The final field is the number of bytes to read. It's little endian format. This value depends on the maximum frame size, negotiated in the “00 01” message. It also depends on the size of the memory block.

This is an example of a MEMORY READ request:

In this case we are requesting 0x64 (100) bytes from the 0013 block, starting from the offset 0.

The response from the PLC is like the following:

In this case, first two bytes (00 FE) say "OK", followed by "00" (unknown meaning). Next two bytes say "you requested 100 bytes, here they are", followed by the 100 requested bytes.

It's perfectly possible to read the whole PLC memory by sending requests like these. I performed a short investigation on this and found that:

Different memory block values were tried from the Modicon M340 PLC. The following values replied with information:

“01 01”, “01 11” to “01 18”, “01 21” to “01 2e”, “01 32”

• Blocks “01 01” to “01 09” replied with the same information, a total of 23Kb.
• Block 0x11h replied with a total of 2048 bytes.
• Block 0x12h replied with 22Kb of information.
• Blocks 0x13 to 0x32 replied with 65Kb of information.

The information returned by the PLC is mostly unintelligible but it seems to be the VxWorks internal OS memory as the first possible memory block starts with “VxWorks 6.4“ (in a Modicon M340).

We known (from a Unity Pro request) that block "01 2E" is asking for "instances of unlocated variables” and it can be seen that unlocated variables are in block 2E and are 03 F7 bytes long.

On the other hand when in Unity Pro we requested for the instances of function blocks, the request sent was for block "01 32" with the same length "F7 03"

UMAS Function Code 0x21

It seems that there is no UMAS Function Code 0x21. I never saw a 0x21 request in any traffic analysis performed by Unity Pro against a Schneider PLC. However, it seems strange that if 0x20, 0x22 and 0x24 function codes read different memory values from the PLC and 0x23 and 0x25 function codes allow to write values, there should be a 0x21 function code as well.

Some tests were performed and all of them returned with error. Possibly PLCs I tested were somehow memory protected and was unable to detect it. If this function code actually exist should have a similar packet structure as the 0x20 request.

UMAS Function Codes 0x22 & 0x23 - READ & WRITE SYSTEM BITS & BLOCKS

Internally Schneider electric source code call these requests UMAS_READ_BOL and UMAS_WRITE_BOL. I don't know exactly what does "BOL" mean but these requests can be used to read and write system bits and words.

There are two ways to read and write system bits and blocks. One of them is using messages “00 22” and “00 23”, the other one is using message “01 50”.

By far the simplest is the first one, but to send it we need first to do some previous work. A CRC value is needed in order this request can return valid values. To obtain this CRC a “00 04” request message needs to be sent and the return CRC32 value needs to be captured.

To read system bits or words we need to use "00 22" request. To write a system bit or word, we need to use "00 23" request.

Reading System bits and words

The packet structure of a 00 22 request is the following, but first let's have a look to a real example:

• After the UMAS code (“00 22”), four bytes are sent. With every strategy (logic) uploaded to the PLC these four bytes seem to be different. After a little bit of research, they are the CRC request in message “00 04” but shifted left one bit, that means, multiplied by 2 (with little-endian format). I will explain how to obtain this "shifted CRC" later.
• After these 4 bytes, the next byte shows the number of System words that are going to be read. In this only 1 (“01”) system word will be read.
• Next byte ("02") is the data type to be read. There is an internal mapping from "02" to "Word" (16 bits)
• Next two bytes (in little endian) "2B 00" indicate the memory block number were these value(s) will be read from. "2B 00" (43 dec) is the "System Words" block.
• Next byte is always 1.
• Next two bytes indicate the base offset of the memory block read. It's codified in little endian.
• The final byte is the relative offset. To calculate it follow these instructions:

  If we are requesting a System Bit, we have to add 4 to the number of the system bit. For instance if we are request System bit 50, the last byte of the request will be 50 + 4 = 54d ==> 36h

  If we are requesting a System Word, we have to add 80 to the number of the system Word multiplied by 2 (because is a word value). For instance if we are request System Word 50, the last byte of the request will be 50 x 2 = 100 + 80 = 180 ==> b4h

  In this second case if the System Word number is higher than 88, the base offset is increased in 1. For instance, let's check System Word 90:

  90 * 2 = 180 + 80 = 260 → 01 04h
  

  Therefore the Base offset will be 01h and the relative offset 04h. The last three bytes of the request will be:

  01 00 04h
  

  An example with 3 system bits and words would be:

  00 22 -- 04 e9 0d 02 – 03 -- 02 - 2b 00 - 01 - 00 00 - b8 -- 01 - 2A 00 - 01 - 00 00 - 06 –- 02 - 2b 00 - 01 - 00 00 - 58
  

  We would be reading two system words (2B 00) and one system bit (2A 00). System words would be “00 B8”, which in decimal is 184 – 80 = 104 / 2 = 52 ==> SW%52 ...and 58h → 88d → 88 -80 = 8 / 2 = 4 → SW%4

  The system bit would be 6 - 4 = S%2

Writing System Bits and Words

In this case we'll use UMAS Function Code "00 23". The structure is very similar, that's why we do not include any image on it:

• After the UMAS code comes the same “shifted CRC” 4 bytes mentioned previously that will be explained later.
• After these 4 bytes comes one single byte that is always "01".
• Next byte indicates the data type (01 for bit, 2 for word, 3 for dword, etc).
• Next two bytes indicate the memory block number, if it's a System bit or System Word ("2A 00" means System bit, "2B 00" means System Word).
• Next two bytes (in little endian) indicate the number of system bit o system word (The offset). This number is codified as previously explained:

  System bit → N + 4
  System word → (2 * N) + 80
  

• The last four bytes are the system bit or word value, in big endian. If it's a System bit, the values can be “00 00 00 00” or “00 00 00 01”.

So, for instance, the following UMAS message:

00 23 - C4 48 C4 37 - 01 - 02 - 2B 00 - B4 00 - 00 00 3A 30

...will be used to write value 00003A30h in System Word #SW50.

The response in this case will be “00 FE 01 00 00”, as only one value was written correctly. Otherwise, if any error happened, “00 FD 01 00 00” will be returned.

How to calculate the 4-byte “shifted CRC” value

1. In our example, the “00 04” message was replied with the following packet:
   

   As it can be seen, in this case the CRC32 read was "82 F4 06 01".

2. It's little endian, so the real value is "01 06 F4 82". Now let's shift left one bit. The result is "02 0D E9 04"
3. Now put it back to little-endian: "04 E9 0D 02"

This is the value we will use when creating "00 22" requests.

There is another way to read and write system bits and blocks. It uses function code 0x0150. It will be explained in a future section of this document.

UMAS Function Codes 0x24 & 0x25 - READ & WRITE SYSTEM COILS & HOLDING REGISTERS

"00 24" request can be used to read coils or holding registers.

"00 25" request can be used to write coils or holding registers.

The request structure of the "00 24" request, is very similar to the previously used by the “00 20” requests:

• The third byte meaning is the number of coils or registers to read. It is usually "01".
• Next byte is always "00"
• Next byte is the Object Type (02 for Coil, 03 for Holding register...)
• Next 32 bits are the starting offset. Little Endian.
• Last 16 bits are the number of coils or holding registers to be read. Little endian.

The "00 25" request structure is a little bit different. At the end of the request we have to add the coils/registers values we are going to write into the PLC:

Let's see an example. In this case we are going to write values 2323h and 5632h to holding registers 1 and 2 using a UMAS request:

"00 25 - 01 - 00 - 03 - 01 00 00 00 - 02 00 - 23 23 56 32"

UMAS Function Codes 0x26 - ENABLE/DISABLE DATA DICTIONARY

I have never seen this request from Unity Pro traffic. However in the piece of internal code I was able to obtain, I found this function code described. I don't really understand what the Data Dictionary is, but I could find that this request structure is the following:

After the function code there's only 1 byte with possible values 0 and 1. Value 0 disables Data Dictionary. Value 1 encables Data Dictionary.

Return codes are very simple as well, 0xFE means OK and 0xFD followed by an unkown bunch of bytes means error.

And this is all for today. In the following part we'll talk about function codes used to upload and download the programming logic of the PLC.