Hack it ! Attack it ! Why and how Hardwired TCP/IP by WIZnet chips (W5500, W7500) makes small MCU systems “unattackable”

W7500 Cortex M0 core is drinking coffee

In the last days and weeks (or 13 years) I was often asked how the chips from WIZnet help to make Systems more stable, better performing and ! more secure.
Here we talk about small MCU with only a few MHz clock speed and FLASH + RAM in kByte size.
“How can that be unattackable ?”“How do you make sure the (real-time) application stay stable ?” and so on.

Here I collected all my e-mail Q&A and post it for you as a compressed text.
I hope you will understand more the background info about:
Hardwired TCP/IP Engine vs. Software Stack.

Performance (2002, 2006, 2008, 2015):

Already starting in 2002, and ongoing, I investigated performance and stability on small 8bit MCUs like 8051 and AVR and how to make them IoT ready.
The only solution to handle all the Internet protocol and on top applications on small MCUs is to offload most (or all) protocol processing out of the MCU => Hardwired TCP/IP = WIZnet’s Chips and Modules.
WIZnet offer 2in1 (hw TCP/IP + MAC) and 3in1 (hw TCP/IP + MAC + PHY) Ethernet controller chips. Additionally WIZnet also offer SoC chips, 4in1 (MCU + hw TCP/IP + MAC + PHY).
In 2002 I used the first chip generation W3100A (2in1) and later here I refer to the latest 3rd Generation W5500 (3in1) chip.

Using hw TCP/IP chips, the bottleneck is only and always the MCU and the MCU’s I/F to the WIZnet Ethernet-Controller.
The limiting factor is the memcopy or xread and xwrite speed for the (external) parallel I/F, or the speed of the SPI I/F.
My investigations in 2002 ended in a small article about “washing-machines to Internet” for the Elektor in March 2003 and proved the 8051 (8MHz) to perform in the lower Mbps throughput range already, an later an AVR performed 8Mbps in 2006.

In 2008 Tom Cantrell from USA made an very detailed investigation & report on the performance and stability boost enabled by the 2008 released W5300 (3in1) chip.
His approach was a bigger MCU (on our W5300-EVB = 200MHz ARM9, 64M RAM + 64M Flash) and an embedded Linux with Software Stack as well as using Hardwired TCP/IP Stack.
With more and more parallel applications launched, in the OS, the Ethernet performance of the software Stack inside the OS goes down dramatically.
=> simple fact: any (real-time) applications is disturbed.
But the exact same Platform and same OS with same Applications prove the outstanding performance advantages of Hardwired TCP/IP.
The Throughput was (is) always above 75Mbps. Any real-time application would be uninterrupted.
Please be assured a Raspberry-Pi II with 1GHz MCU can pump 111MBps into the 100baseTX Ethernet, unimpressed, yes, but try this with several application launched parallel => performance goes dramatically down.
You would be happy to have stable 75Mbps and some less Interrupts for your other tasks.
Here a picture from Tom’s 2008 Circuit Cellar #218 article:

W5300 Hardwired vs. Software Stack
W5300 Hardwired vs. Software Stack

Tom concluded:

W5300 boosts performance and stability
W5300 boosts performance and stability


And now in 2015 with our latest 4in1 SoC (48MHz Cortex M0 + Hardwired TCP/IP + Ethernet) we can present the most best Internet Protocol performing ARM Cortex M0 MCU of the world, as we think.
Roy “embeddist”, one of our chip design engineers did tests on the “Attack” part of this performance Story.

(1) Firewall SoC with TCP/IP Offload Engine

(2) Network performance of W7500 SoC with TCP/IP Offload engine – using DMA

Even a double speed and 5 time more memory ARM Cortex M3 MCU, with much more complex core, can not perform as good as our small & simple (Hardware supported) M0 MCU – W7500:

W7500, the unattackable
W7500, the unattackable “Firewall” SoC for the IoT

Here his findings:
Roy’s Blog about the W7500 performance compared to the M3. Just click on the Pictures:

W7500 Cortex M0 vs M3 performance under Attack
W7500 Cortex M0 vs M3 performance under Attack

And using DMA is boosting the performance to even 45 Mbps ! on that small M0 !

W7500 performance using DMA
W7500 performance using DMA .. 45Mbps

Our small ARM Cortex M0 in the W7500 SoC just outperform the bigger M3 by factor 3 to 10 so easy and does not allow any “Attack” to disturb it’s main Target application.
With offloaded = Hardwired TCP/IP Protocol there is no Interrupt, so the performance stay high, a real time application would stay stable.

Stability – Security – Unattackable – Unhackable

To tell the same story with even bigger words I like to go into some more details.
Regarding “unattackable” and “security” I like to add some detailed info here.
The TCP/IP offload Engine (ToE) is pure silicon gate logic, no MCU or FPGA or any code from Flash or ROM mask is executed inside that ToE chip.
As all the IP (Layer 3) and UDP + TCP (Layer 4) protocol is executed by gate logic, so, it’s very very fast and unattackable on that level already.
The TCP/IP engine exist 8 time parallel. The status and data of up to 8 connection can be handled at same time – really parallel. By the way, any special IP- or MAC-Layer protocol can be implemented anyway in software as there is a direct access pass-through the Socket 0 engine.
In Hardware, all protocol handshaking, automatic answer processing, packet check sum and extracting data is fully handled by the ToE without interrupt for the on top (or your) MCU (our our W7500 M0 core).

Here the TCP handshaking from Server point of view is like a telephone call – and all that is a pure hardware status machine:

TCP/IP Server Status Machine
TCP/IP Server Status Machine

+ switch your telephone on

+  wait a call coming => become Server

Receive a SYN:
+ phone is ringing

Answer with a SYN – ACK:
+ press green button and say: “Hello ?”

Receive ACK:
+ hear: “I like to talk to you”

Then you are ESTABLISHED
+ exchange data by send and receive chat

Additionally to the Status machine and protocol (ToE) engine we have 32k of dual ported RAM in all our Chips to store send and receive (at same time) the raw application data. So the raw data is in that external 32k memory and not in the MCU’s memory before you memcopy it for handling, of cause.
=> So, there is no Operating System or any Interrupt machine needed on your MCU to make Internet applications like Web-server, Gateway or other Application. And our chip (or ToE) is acting with high performance and is just external memory (separated address area) to the MCU. All timing critical part is handled by the ToE. The MCU can do the (real-time) Application part with priority.

And even if there is a virus or bad data in the raw data memory ?
Who can execute code in external RAM ? There is no OS and this RAM is no code memory.

On top security (Layer 5 – 7), other story:

We implemented TLS 1.2 (transport layer security) using STM32F103 and F205 (for reference) the last two years with strong crypto algorithms together with 3rd party help. That 3rd party is Escrypt (embedded crypto) and Steen-Haarbach (system consultant) and the full implementation is automotive graded MISRA standard C code.
Incl. a small demo web-server (https) the TLS client and server together (+ 3 certificates) needed just ~ 50k of Flash and a few 3k to 5k of RAM memory (dynamically). That implementation is done in a most slim way and without any OS or interrupt call.
We (and our partners) can license this implementation to any customer. Porting to other MCU is supported by Steen-Harbach.

All that together is what we call “unattackable” because the Hardwired TCP/IP can not be “hacked” or passed by any virus or “attacked” by a DDOS attack. And the Key exchange for encrypted data is secured against man in the middle the best way.

Why? In the higher level application there is no Interrupt system and no OS, so no external code can be executed. And, in the MCU, the crypto and TLS also work without interrupt. If you like you use secured memory or crypto smart card co-processor to make it even physically much more un-hackable. You can level up as you like.

  • There is no way to hack or attack an OS that is not there.
  • You can not unintended execute a Virus in external RAM memory, specially without OS.
  • The performance is always very good, as no Interrupts. Even under attack.
  • The source code is very small and can be easy certified or audited as there is no (or if, a very small) OS.
    => There is dramatic cost difference if you like to have a audit on many 100,000 lines, or just a few hundred lines of C code w/o Interrupt system!

“Attack” Scenarios:

  • 1.) the W5500 (ToE) or W7500 application is a Client (like Browser)
    • a) that’s never ever any problem. Even if the Ethernet itself with it’s max performance of ~ 111 Mbps is flooded on the Physical Layer, there is always a few kbps left to send out the SYN and make the connection. But if your network is that occupied (flooded) on PHY Level already, you have a different and much bigger problem.
    • b) I don’t know …
  • 2.) the W5500 (ToE) or W7500 application is the Server = one or more Socket in LISTEN status:
    • a) the socket connection is ESTABLISHED by a client and stay connected, then:
      No one can break that connection down – as long as it stay ESTABLISHED , don’t close from either side.
      But even if it’s closed it can be ESTABLISHED again as long as a socket can go into LISTEN status again.
    • b) flooding attack goes to the open Socket before the (by your application) intended connection.
      • 1.) if the SYN flooding goes to any random port numbers or any ARP or Ping, then no problem.
        Your LISTEN Socket stay or can be closed & re-initialized at any time, very fast.
      • 2.) if the flooding open exactly that specific application port with a SYN then your trapped – in some way.

But your not really trapped here:
As told before the W5500 (ToE) supports up to 8 sockets at same time parallel. If all 8 sockets are connected = ESTABLISHED (by a very specific attack as 2.b.2.), then no other client can access any more, until one of the sockets is closed and re-init to LISTEN again. But any next first client SYN (maybe attack) will connect again….
Yes, your application Socket is not available most of the time = DDoS success, but:
If there is a specific SYN flood attack on your specific application Socket you (the MCU) need to be fast to close them again and again and again to make it LISTEN for your intended Service – or avoid System Overflow. That’s very little load on the MCU with the ToE does it all, but a lot (sometimes too much) for an OS.
Compare again the two options:

  • MCU + operating system (embedded PC ..) = Software Stack.
  • MCU + W5500 (ToE) = together like the W7500 = Hardwired Stack.

The ToE is very very fast in switching and processing socket status, it’s ‘only’ Gate-Logic, so your MCU just need to assist or control that, from time to time, not timing critical.
That Scenario 2.b.2. is also the case with every embedded PC (Raspberry Pi, Beaglebone…) or even a big server in a Data-center – doing that all in Software with a lot of interrupts and memory to store all the status data … even worse.
=> it’s overrun by Interrupts and eventually out of memory = overflow.
The 8 parallel Sockets in our (ToE) are real parallel ! + supported by internal 32k of dual ported RAM for read and write from both directions at the same time.

Our Hardwired TCP/IP engine (ToE) is ~ 200 times faster in answering and analyzing Packets then a fast Intel Core i7 PC (2 GHz, 8GByte). We tested this 8 processor PC (Core i7) while coding the TLS on the small STM32F103 MCU (~ 50MHz, 20k RAM memory, 128k Flash) just by accident as a communication partner. The i7 was too slow !
Yes, the i7 can send data with ~ 200 or 300 Mbps to the GBit Ethernet but need time to process interrupts with every single packet that comes along. To answer a single PING, SYN, ARP, …  packet  or drop it as useless, the i7 (with Windows 7 pro) is not as fast as the W5500 or any other ToE chip directly.
Even worse if the (embedded) PC need to check all ESTABLISHED TCP connections and close them faster as they pop open in an attack – just to make one of them LISTEN again. No chance.
Even in an worst case attack (and specially in that scenario) maybe directly to your application Socket (Port) a small MCU + W5500 or W5300 (ToE) or the W7500 outperform any OS on any big CPU or MCU.

At least your (real-time) application stay un-attacked and fully available.

I invite you to give that a try:
Hack a non OS Application (maybe the Web-server on the WIZ550web module) using WIZnet’s ToE chips.
Or, bring such an OS less application totally down by DDOS Attack.

best regards,
Joachim Wülbeck
Product Manager Europe / Field Application Engineer
WIZnet Europe GmbH


W5500CoB the W5500 Connector on Board Module used with Espruino Pico – BreadBoard setup

Espruino Pico and W5500CoB

After setting up the Break-out-Board W5500BoB (-> Blog) last week I set up the ‘sister’ W5500CoB (-> Wiki) Module from ESoPe here.
This Connector on Board Module is 1:1 compatible for the MCU I/F (8 pin 100mil Pin-Headers) but it includes the RJ45 connector on Board.
So there is also the W5500 chip on the Module and I connected it by SPI again with the same Espruino Pico:

  • W5500CoB module (W5500 + xtal + passives + RJ45 connector)
  • Espruino Pico (STM32F401 MCU … JavaScript engine)

This is how the BreadBoard look like:

W5500CoB with Espruino Pico
W5500CoB with Espruino Pico

Here also the detailed Schematic (PDF) in a BlockDiagram style:

SPI connection of W5500CoB and Espruino Pico
SPI connection of W5500CoB and Espruino Pico

2015-05-06_W5500CoB_MCU_001 (same as PDF file here for download)

I think all other Info is in the former Blog entry (W5500BoB), so I don’t need to double all info here again.

Best regards, Joachim