You want Retro? We did, when we started our retrocomputing challenge. [Peter] decided that transistors weren’t retro enough, and sent us this lovely homebrew relay computer, complete with 16- bit CPU, which is rather more bits than one normally associates with clicky clacky contacts.
The architecture is very simple– it just uses an accumulator register, ACCU, and goes from there. All mathematics and save/load operations go through ACCU. There whole instruction set is only 19 commands, and he’s used that set to program such lovely things as calculating 3 digits of Pi– which only took 8 minutes of glorious clicking. There’s a demo video of that embedded below. [Peter] has even implemented a display by hooking his computer to a 32×32 LED matrix, but don’t expect it to relay updates really quickly.
If this computer looks familiar, it’s because its earlier incarnation was one of the more “extra” entries in last year’s one-hertz challenge, where it was used to blink an indicator lamp. Yes, even relay computers apparently get started with the “blinky” sketch.
If you want in on the fun, our retrocomputer challenge runs until October 27th, so there’s lots of time left to turn back the clock.
The earliest all-electronic computers used vacuum tubes, and most of us will know about machines such as ENIAC or Colossus. Vast machines that required the budget of a country at war to build, andfill very large rooms. It’s very pleasing then to see that a useful vacuum tube computer can be made which has neither of these requirements, as with this example from [Mike] that uses former eastern bloc double-triodes.
It’s an 8-bit design following a von Neumann architecture with 16 instructions, whose operational block diagram would be instantly recognisable to anyone used to working with a 1970s-era 8-bit microcomputer. It follows a NOR-based design in the same manner as the famous NASA machines from the Apollo programme, and as we understand from the description it uses more modern parts for its I/O circuitry. Physically it’s a surprisingly compact wall-mounted unit, and it has an accompanying ex-British Rail flip-digit display as well as a control panel for a simple airship simulator game. There’s a website with full details, if you are interested.
We like this machine, a lot. It may not be the largest computer we’ve seen and it certainly isn’t the first one with vacuum tubes, but it’s a very impressive achievement to have created it. If tubes in computing interest you meanwhile, we took a trip to see the daddy of them all.
Quantum this, quantum that…who put a stupid cat on-chain!?
Ahem.
Alright, let’s be serious. The threat that a viable, actually functioning, quantum computer would pose to Bitcoin if it were to be built is very serious. It is the concrete example of an existential threat, in every sense of the word.
One of the bedrock foundations that Bitcoin rests upon is the assumption of a functioning cryptographic system that can be used to produce unforgeable signatures, i.e. that if you follow that system’s protocol properly when signing things, there is no way that anyone but a bitcoin’s rightful owner could produce a signature needed to spend it unless the rightful owner failed to secure their private key from theft.
Quantum computers toss that right out the window. There goes the integrity of the entire mechanism that is used for owners of bitcoin to authenticate their ownership for the protocol to process their legitimately authorized transactions, and ONLY their legitimately authorized transactions. There’s no way for anyone to actually own anything in the context of the Bitcoin protocol if that assumption breaks.
Bitcoin breaks if that assumption breaks.
Thankfully, there are many different cryptographic systems that exist, and not all of them rest on assumptions that a quantum computer breaks. That’s the good news. The bad news is that its all a set of tradeoffs, none of them are ideal, and there are going to be some hard choices that have to be made.
But there are solutions to just about every one of the problems that a viable quantum computer would create…except the problem of choosing which solutions to use. So in light of that, here is The Quantum Issue.
This issue is a lot more structured than most past issues, and that is to ensure that it guides a reader through the entirety of the problem space and solution space without assuming any prior understanding (this is a very deep and technical subject).
The first set of articles goes through the general issue of quantum computing itself, how it differs from classical computing, why that matters, how likely it is one is developed soon, etc.
The second set examines Bitcoin’s exposure. How is it exposed? How badly is it exposed? How can that degree of exposure change?
The third set examines concrete (or developed enough to not be too hard to get to a concrete place) solutions to securing your bitcoin in a quantum safe way, and handling a network wide migration to those solutions.
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Quantum Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
The concept behind the project is simple enough—grab the digital signals that feed the MC6847 IC responsible for generating the analog video output, and use them to create an all-digital video output over HDMI. [Scott] achieved this by using a Tang Nano board, which hosts a Gowin GW1N-1 FPGA. It’s able to snoop the signals heading to the MC6847 and, with some supporting components and level shifters, it can spit out video befitting modern screens. To make the system nicely complete, an analog-to-digital converter is also included to pick up the analog sound output from the TRS-80 and spit it out down the same HDMI cable. Such convenience!
There’s something strangely anachronistic about grabbing a TRS-80 off the shelf and hooking it up to a flatscreen with a single HDMI cable. Regardless, it’s a pretty great way to play with your old machine without having to futz with heavy old CRTs. We’ve featured plenty of similar projects before, too.
What is it about retrocomputing? For some people, it’s nostalgia. For others, it’s the appeal of simplicity. For still others, it’s the chance to save old machines from the graveyard. Whatever your motivation, there’s no denying that we’ve seen a metric ton of retrocomputer projects here at Hackaday. And we’d like to see more!
Now’s the chance to put your retrocomputer project up for all to see. Open up a Hackaday.io project that features your retrocomputer project, and we’ll pick our three favorites for a $150 gift certificate courtesy of this contest’s sponsor, DigiKey. You have until Tuesday, October 27th. So get hacking!
Honorable Mention Categories
Old Iron: Are you saving an old C64 from the scrapyard? Restringing the core memory of a PDP-8? Or working on even more esoteric ancient devices? If you’re restoring or running the old hardware itself, it’s an “Old Iron” project.
Modern Retro: Computing power is plentiful, but the nice interfaces of past computer made them a joy, or a terror, to use. This honorable mention category is for emulations, work-alikes, and all the other retrocomputers that are TRS-80 on the outside, but modern electronics on the inside.
Retro-Modern: You love your classic machine, but you also love reading Hackaday on the Internet Of The Future, so you built a web-modem to bring the old beast into the modern era. This category is for keeping old hardware relevant.
Coding Like It’s 1999: Retrocomputers don’t run without software, and it’s a continual source of amazement to us how programmers today can get more out of old machines than we could back in the day. Think of the demoscene, for instance. But it doesn’t have to be showy either. If you’re writing new code for old boxes, it fits in here.
In the 1960s, the home computer was barely a twinkle in anyone’s eye. This was the decade in which computers were used by a handful of companies and organizations and took up entire rooms. It was the decade that saw the birth of the first integrated-circuit computer, the Apollo Guidance Computer, and, rather strangely, one of the first home computers of sorts: the Digi-Comp 1.
In 1963, E.S.R. introduced this little programmable educational toy computer. It relies on simple mechanical logic gates, programmed by positioning tubes on sliders. Their original intention was to create actual computers, but one thing led to the next, and E.S.R. became the premier educational computer toy company of the 1960s. The Digi-comp is a rather simple device. A program is entered by soda-straw-like tubes placed on sliding rails. These tubes interact with spring-loaded levers which move in accordance with the “clock” switch. The result is a simple binary computer you can program.
[Chris Staecker] got a remarkably well-preserved Digi-Comp I to demonstrate its unique functioning. With some rubber bands and a touch of modern technology in the form of 3D printing, [Staecker] got the toy working like new. The programming process is quite manual, and its functioning is not obvious. But it can compute binary outputs of given functions. Unfortunately, this is not a Turing-complete process, but rather a state machine with 88 (or 16,777,216) possible states. The toy, with all its limitations, is highly reflective of the state of computing at the time, and a rather neat look at what the future was, back in 1963.
A while back, we walked you through building your own hacking drone. It was a drone loaded up with tools designed to help you out during an actual pentest. That was a hands-on project in every sense of the word. If you built one, you probably learned a ton just from putting the hardware together.
This time, we’re doing something different. No soldering iron. We’re staying entirely inside your laptop working with the Damn Vulnerable Drone, which is an open-source simulator built for teaching you exactly how drones get hacked, without you ever touching a real drone.
The Damn Vulnerable Drone
The Damn Vulnerable Drone, or DVD, is a training simulator that was made for people who want to learn drone hacking without buying a drone. It recreates an entire drone system in software, including a flight controller, an onboard companion computer, a ground control station and the wireless links connecting them all. Every piece is there, and every piece runs inside Docker containers on a single computer.
The project was built by Nicholas Aleks, a security researcher and co-founder of DEF CON Toronto, and it’s aimed squarely at intermediate-level red teamers and hacking enthusiasts who want to practice with actual drone protocols and architecture. Drone hardware and radios are genuinely expensive, and a mistake on a real flight controller can be costly. You get to make your mistakes safely, over and over, until you actually understand what you’re doing. DVD runs actual ArduPilot firmware as an ordinary program and pairs ArduPilot’s SITL with Gazebo, which is a 3D robotics simulator that supplies realistic physics. Motors spin up, GPS signals drift the way they really do, and the drone actually flies through a rendered 3D world.
Under the Hood
Every Docker container gets its own address on an internal network. That’s a design choice that mirrors how a real drone’s components actually work. The first piece is the Flight Controller, which runs the ArduPilot firmware itself and talks directly to the Gazebo simulator to process virtual sensor data. The second piece is the Companion Computer, which handles Wi-Fi, camera streaming, telemetry logging, and autonomous navigation, and which also exposes its own web interface for you to interact with. The third piece is the Ground Control Station, the pilot’s side of the operation, covering mission planning, mapping, video, and joystick control, all communicating over a simulated wireless MAVLink link. And the fourth piece is the Simulator itself, the Gazebo container that models flight physics behind the scenes. The documentation specifically tells you not to attack this fourth container directly, because doing so can crash the entire lab out from under you. Everything else is fair game. That one, leave alone.
Getting Started
To install it we need to pull down containers. The project offers two configurations based on whether you have a dedicated graphics card.
If the answer is no, you need Lite Mode. It uses a simplified 2D flight model, needs no GPU at all, and runs comfortably on 4 to 8 GB of RAM, 2 CPU cores, and about 100 GB of disk space. It works on Kali Linux or most other Linux distributions, and you can run it either on bare metal or inside a virtual machine. If the answer is yes, Full Mode gives you the complete Gazebo 3D environment, but it asks more of your machine in return. You need 8 to 16 GB of RAM, 2 to 4 CPU cores, 100 GB of disk space, and a GPU with at least 2 GB of VRAM supporting OpenGL 3.0 or newer. Full Mode is Kali Linux only, and it strongly prefers bare metal, though a virtual machine with GPU passthrough will also work.
Kali Linux is the officially supported operating system either way, and both modes need Docker and Docker Compose installed as the only real software dependency you have to worry about. Once Docker is installed, the whole lab comes up with a handful of commands.
First, if Docker isn’t already on your system, you’ll want to install it:
kali > printf '%s\n' "deb https://download.docker.com/linux/debian bullseye stable" | sudo tee /etc/apt/sources.list.d/docker-ce.list
kali > curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker-ce-archive-keyring.gpg
kali > sudo apt update -y
kali > sudo apt install docker-ce docker-ce-cli containerd.io -y
kali > sudo systemctl enable docker --now
kali > sudo usermod -aG docker $USER && newgrp docker
Then, clone the repository and pull down the containers. If you’re going with Lite Mode, do this:
kali > git clone https://github.com/nicholasaleks/Damn-Vulnerable-Drone.git && cd Damn-Vulnerable-Drone
kali > docker compose -f docker-compose-lite.yaml pull
From there, three small scripts manage the whole lab’s lifecycle for you:
kali > sudo ./start.sh --mode lite --Wi-Fi wpa2
kali > sudo ./status.sh
kali > sudo ./stop.sh
The start.sh script alone has quite a few options worth knowing about. The –mode full or –mode lite flag picks your simulation type, matching the two modes described above. And the –Wi-Fi wep or –Wi-Fi wpa2 flag is optional, but it’s worth turning on, because it spins up a virtual wireless network alongside everything else. That means your practice can actually include real Wi-Fi attacks as the very first step, instead of starting the exercise with network access already handed to you.
Interface and Feedback
Once everything is up and running, DVD is controlled through a browser-based management console sitting at localhost:8000
This console is really where the whole exercise plays out. A set of buttons trigger five distinct flight states: Initial Boot, Arm & Takeoff, Autopilot Flight, Emergency/Return-to-Land, and Post-Flight Data Processing. Each one simulates a different phase of a drone’s mission and opens up a different attack surface for you to explore. Triggering “Arm & Takeoff,” for instance, actually gets the simulated drone airborne, which gives GPS and navigation-based attacks something real to act on.
That mapping to real flight phases is there for a reason. A drone accepts different commands, and trusts different sources of data, depending on whether it’s sitting idle on the ground, climbing out after takeoff, cruising on autopilot, or executing an emergency fail-safe. That means exercises built around each individual state end up testing different parts of the system.
The Attack Scenario Library
This is really the heart of the whole project. It has more than 40 named attack scenarios, organized into six categories, each one with its own documentation page and a spoiler-tagged walkthrough waiting behind it. It’s a deliberately broad menu, and it’s worth noticing that some scenarios are about gathering information without being noticed, while others are about actively manipulating or outright breaking the system in front of you.
Reconnaissance scenarios are about passively fingerprinting the drone, its companion computer, and its ground station by watching Wi-Fi and MAVLink traffic go by, without touching anything yet. Protocol Tampering scenarios involve spoofing telemetry values the drone reports, things like its GPS position, battery level, or system status, to see whether the system properly checks what it’s being told. Denial of Service scenarios focus on disrupting flight through methods like Wi-Fi deauthentication or flooding the communication link until it can’t keep up. Injection scenarios involve sending forged commands directly into the MAVLink stream, ranging all the way from a simple waypoint change to a full companion-computer takeover. Exfiltration scenarios are about pulling data off the drone entirely, whether that’s flight logs, mission plans, or content from the camera feed. And Firmware Attacks focus on modifying or reverse-engineering the ArduPilot firmware itself, right down at the code level.
Battery Spoofing
Because every scenario runs against fully simulated components, you actually get to see the complete effect of an attack play out. A spoofed GPS reading really does nudge the simulated flight path off course. A flooded communication link really does degrade control, right in front of you. And you get to watch all of it happen without any of the legal or physical risk that would come with testing the same techniques on live hardware.
Wi-Fi and Non-Wi-Fi Modes
DVD can be deployed in two different ways, and which one you pick depends on which part of the attack chain you actually want to practice. Wi-Fi Mode spins up a real, functioning virtual wireless network, broadcasting an SSID called Drone_Wi-Fi on the 192.168.13.0/24 range, with your choice of weak WEP encryption or the considerably stronger WPA2. This lets the whole exercise start from the very beginning, with you playing the role of an attacker who doesn’t have network access yet and has to earn it.
Non-Wi-Fi Mode skips that entire step and simply brings the containers up directly. This is useful if you just want to focus purely on protocol-level attacks, or if you’re not running inside a Kali VM with wireless card support to begin with. In this mode, the documentation asks you to treat the situation as though initial access to the drone’s data link has already been established, so you can jump straight to the MAVLink-level work.
Summary
The Damn Vulnerable Drone takes an idea that’s already well proven in web security and applies it to a domain where practicing on the real thing tends to be expensive. By simulating a full ArduPilot and MAVLink drone stack inside Docker, right down to Wi-Fi, camera streaming, and flight physics, it hands penetration testers, students, and researchers a realistic, disposable target, backed by more than 40 documented attack scenarios and built-in walkthroughs to guide the way. It won’t teach you to fly a real drone. But it will teach you exactly how one can be hacked, and for anyone working in drone security, that’s the more useful skill anyway.
If you’re interested in drone hacking, check out our Building Your Own Hacking Drone series, where we walk you through attack scenarios targeting Bluetooth and Wi-Fi across a wide range of devices.
We also offer a Drone Hacking training course, taking place November 10-12 at 4:00 PM UTC, available to Subscriber and Subscriber Pro students.
Login
, so you built a web-modem to bring the old beast into the modern era. This category is for keeping old hardware relevant.
