Around these parts, [Peter] is well-known for abusing the TRS-80 to do things it should never do. You can read Wikipedia on the TRS-80, you can look at Google Images, and you can browse the web. As with any retrocomputer, there are limitations for what you can do. To browse Wikipedia, [Peter] had to set up an AWS instance which translated everything and used serial to IP converters. It can be done, but it’s hard.
Now, after seeing a few interesting projects built around the ESP32, [Peter] built a network card for the TRS-80. It’s called the trsnic, and it’s a working network card for almost all the TRS-80s out there, with the eventual goal of supporting the TRS-80 Model I / II / III / 4 / 12 / 16 / 16B and 6000.
The idea for the trsnic comes from [Arno Puder]’s RetroStoreCard, a device that plugs into the TRS-80 Model III and connects it to a ‘personal cloud’ of sorts that hosts and runs applications without the need for cassettes or floppys. It does this with an ESP32 wired up to the I/O bus in the Model III, and it’s all completely Open Source.
[Peter] took this idea and ran with it. Thanks to the power found in the ESP32, real encrypted Internet communication can happen, and that means HTTPS and TLS.
Right now, documentation for the trsnic is limited, but the project does exist and building it is as easy as stuffing some headers and DIP sockets in a PCB and soldering them on. There’s a bit of work to do on the ESP32 code, but if you’re looking for a network card for your Trash-80, this is the one that works now.
Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.
With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.
Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages”
Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.
Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.
Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”
[The Backwoods Engineer] tested out a new accessory kit for the STM32-F4 Discovery board. The image above shows two boards communicating with the UDP protocol. Notice the extra PCB into which each Discovery board has been plugged. This is a third-party add-on which adds Ethernet, RS-232, SD card slot, and a connector for LCD or Camera. We’ve had one of these F4 Discovery boards on hand for a while and haven’t figured out a good way to connect external hardware to the huge dual pin-headers. This doesn’t solve the problem — the base board also includes dual headers to break-out all the pins — but having Ethernet, serial, and SD certainly reduces the need to add all that much more. The other drawback to the hardware is that the sample firmware is targeted at the IAR Embedded Workbench which is neither free, nor in the realm of affordable for hobbyists.
The NIC used on the baseboard has auto-crossover capabilities so the boards were connected using a regular Cat6 patch cable. This example has the boards constantly sending UDP packets with the module on the right reporting status information to a terminal via the serial connection.
We’ve said it time and again, the Arduino is a prototyping platform. In that spirit, [Doug Jackson] shows you how to conserve the expensive Arduino board and Ethernet shield by building your own Arduino Ethernet module. You may remember the ENC28j60 as a NIC for your microcontrollers. [Doug’s] board makes use of that chip and adds an ATmega168 with a crystal, power regulator, breakout pins, and even a few DIP switches which can come in quite handy.
While Black Hat and Defcon have both concluded, we’re going to post a few more talks that we think deserve attention. [Sherri Sparks] and [Shawn Embleton] from Clear Hat presented Deeper Door, exploiting the NIC chipset. Windows machines use NDIS, the Network Driver Interface Specification, to communicate between the OS and the actual NIC. NDIS is an API that lets programmers talk to network hardware in a general fashion. Most firewalls and intrusion detection systems monitor packets at the NDIS level. The team took a novel approach to bypassing machine security by hooking directly to the network card, below the NDIS level.
The team targeted the Intel 8255x chipset because of its open documentation and availability of compatible cards like the Intel PRO/100B. They found that sending data was very easy: Write a UDP packet to a specific memory address, check to make sure the card is idle, and then tell it to send. The receive side was slightly more difficult, because you have to intercept all inbound traffic and filter out the replies you want from the legitimate packets. Even though they were writing low level chipset specific code, they said it was much easier to implement than writing an NDIS driver. While a certainly a clever way to implement a covert channel, it will only bypass an IDS or firewall on the same host and not one on the network.
[photo: Big Fat Rat]