I wanted to manage them from code. My first plan was to script that web UI, where the settings sit in JavaScript objects inside HTML pages and every change is a GET request to a .cgi page, which works but is chatty and brittle, and any firmware update can move things around. So I looked for another way in. Terraform comes in at the end.

Port scan and discovery

The first question was what the switch listens on. A connect scan of the usual management ports (21, 22, 23, 69, 80, 161, 443, 8080, 8443 and a few more) found only TCP 80 open. snmpget timed out. No SSH, no telnet, no HTTPS.

TP-Link also ships a desktop tool, the Easy Smart Configuration Utility, that finds switches on the network and configures them without a browser. So something else was talking. Earlier open-source clients, mainly smrt and its forks, had already mapped the outline: UDP, port 29808 on the switch, replies to port 29809 on your machine, and only inside one layer-2 segment, meaning no router in between. I sent a discovery broadcast and both of my switches answered with model, MAC address, firmware version and hostname. No password needed. My project calls this protocol ESCP.

The appeal over the web UI is practical. The payload is typed binary instead of HTML and JavaScript, one GET can ask for several settings at once, and discovery needs no credentials and does not depend on the switch's IP configuration, so it still finds a switch whose address is wrong. A UDP switch is also far easier to fake in tests than a stateful web server.

Unpacking the vendor tool

The utility is a Java program wrapped in an InstallShield .exe, which macOS cannot open. I carved the embedded CAB out of the installer and unpacked it, then found that the application executable has a jar appended to it, which you locate through the zip end record:

# schematic: the carving steps were scripted
unshield -d out x data1.cab    # exits 1 over one unrelated file; the application still comes out
jadx -q -d decompiled app.jar  # decompile the jar carved from the application exe

The class names are obfuscated, but numeric constants survive. The decompiled sources contain 148 distinct ones, and most of the protocol's setting identifiers sit together in one obfuscated class, with a few more in two others.

What a packet looks like

A 32-byte header, then a list of TLVs: type, length, value.

Python reads the header in one line:

struct.unpack("!bb6s6shihhhhi", packet[:32])
# version, op, switch MAC, host MAC, sequence, error,
# total length, fragment, flag, token id, checksum

The ! means network byte order with no padding. The op field says what kind of packet it is: discovery, a read (GET), a write or login (both share one op value), or a reply to one of those. A reply carries the sequence number of the request it answers, so the client can ignore stray packets. Strings end in a NUL byte, and the payload ends with ff ff 00 00.

The settings are numbers, all decimal here. LED on or off is type 12 with one byte. Port settings are 4096, QoS mode is 12288, IGMP snooping is 4352. There is no names table on the wire. I got the numbers from the vendor's code and from earlier clients, and checked each one on the real switch.

Two RC4 variants

Discovery and the key-exchange packet use RC4, an old stream cipher that is still common in embedded devices, with a static 256-byte key. The vendor stores that key encrypted inside the jar with TEA, a small block cipher, and ships the decryption routine in the same file. I decrypted it and compared the result with the key smrt had hard-coded, and they matched, which is how I knew the derivation was right. The key ships in every copy of the software, and the cipher is re-initialised for every packet, so there is no stream to keep in sync.

Once the key exchange succeeds, traffic switches to a per-session RC4, keyed with a random eight-character string. The state array in this one has eight entries instead of 256, the same algorithm at toy size. I don't know why. The switch expects exactly this, so the client produces it.

What changed in the 2023 firmware

Earlier clients logged in by asking for a token id and then sending the username and password. The release notes for firmware 20230218 say the management protocol was "upgraded to enhance security", so that flow almost certainly would not work on my switches. I did not test it.

Two firmware images were available, 20220930 and 20230218, so I could compare them without any disassembly: extract the printable strings from each and diff the lists. Among the new strings, two mattered. One was RSA_private_decrypt, with its error and success messages. The other was a cookie session for the web UI. That suggests the switch now holds an RSA private key, and expects the client to send it something encrypted. Whether the key is per device or shared by every unit, I have not checked.

The jar has a class that does exactly this. The new handshake is two round trips:

1. The client generates the random session key and sends it in a SET packet with TLV 528. The key is encrypted with textbook RSA, which means the raw maths with no padding: exponent 65537, the number stored as little-endian words. The packet itself goes out under the static RC4.

2. The switch replies with error code 4098, which despite the name means "session key accepted". The meaning comes from the vendor code that handles the reply.

3. The client sends the username and password as TLVs 512 and 514, now under the session RC4.

4. The switch replies with code 0, and you are in.

The RSA operand is the one little-endian thing on the wire; everything else is big-endian.

The RSA modulus for the TL-SG108E v6 is only 64 bits long. The vendor utility carries a 1024-bit one for other models and uses the short one for mine. 64 bits offers no real protection.

There is no session token. Every write carries the username and password again, while ordinary reads need no credentials, only the key exchange first (I did not test reads without it). The config backup read below is the exception, since it is an authenticated SET.

Verifying on the real switch

A decompiler can mislead you, and the only switch I could log into is on my live network. It has no console port, and the recovery from a bad write is a physical factory reset. So I set rules before sending anything: reads first, cross-checked against the web UI where I could; the LED as the first write, since it is harmless and trivially reversible; and a config backup before any write, a continuous ping running in another window, and experiments on unused ports 6 and 7 only.

The LED toggle worked and the web UI agreed, but the config backup told me more about the protocol itself: an authenticated SET with an empty TLV 768 makes the switch return its whole configuration file, and because that does not fit in one UDP packet the reply comes in fragments, with the fragment field in the header set to 1 on every packet but the last and the client stitching the pieces together. The result was 2258 bytes starting with the magic bytes 23 89 23 89, byte-identical to the file the web UI downloads.

Some behaviour only shows up on the real device:

Security

There is no integrity check, every installation shares the same cipher key, the RSA key is 64 bits, and every write carries the password. Anyone who can capture traffic on that segment, including the key exchange, can recover the session key and the credentials, and nothing in the protocol authenticates the switch's replies to the client. TP-Link's own utility does the same, so it is the protocol rather than my client. Put switch management on its own VLAN and keep it away from networks you don't trust.

Status

All authenticated testing was on one device, a TL-SG108E hardware v6 running firmware 1.0.0 Build 20230218. Discovery also answered on a second switch with newer firmware, which I could not log into. If you have another Easy Smart model or a different firmware, I would like to know whether the same handshake works for you.

I turned this into a Terraform provider: github.com/davidlukac/terraform-provider-tplinkeasysmart, also on the Terraform Registry. The protocol notes live in the repo as PROTOCOL.md, with the TLV tables, in case you want to write a client in another language.

I did this with Claude Code, an AI coding assistant, which read the decompiled code, wrote the client and its tests, and ran the experiments under the safety rules I set.