When [Nishanth]’s Subaru BRZ came to a sudden halt, he was saddened by the wait to get a new engine installed. Fortunately, he was able to cheer himself up by hacking it into a car simulator in the mean time. This would have the added benefit of not being limited to just driving on the Road Atlanta where the unfortunate mishap occurred, but any course available on Forza and similar racing games.
On paper it seemed fairly straight-forward: simply tap into the car’s CAN bus for the steering, throttle, braking and further signals, convert it into something a game console or PC can work with and you’re off to the races. Here the PC setup is definitely the cheapest and easiest, with a single part required: a Macchina M2 Under the Dash kit ($97.50). The XBox required over $200 worth of parts, including the aforementioned Macchina part, an XBox Adaptive Controller and a few other bits and pieces. And a car, naturally.
The Macchina M2 is the part that listens to the CAN traffic via the OBD2 port, converting it into something that resembles a USB HID gamepad. So that’s all a matter of plug’n’play, right? Not so fast. Every car uses their own CAN-based system, with different peripherals and addresses for them. This means that with the Macchina M2 acquired, [Nishanth]’s first task was to reverse-engineer the CAN signals for the car’s controls.
At this point the story is pretty much finished for the PC side of things, but the XBox One console is engineered to only accept official peripherals. The one loop-hole here is the Adaptive Controller, designed for people with disabilities, which allows the use of alternative inputs. This also enables using a car as an XBox One controller, which is an interesting side-effect.
One final gotcha with the XBox version was that the Adaptive Controller doesn’t allow one to control the triggers from its USB port, so they had to use the 3.5 mm (analog) inputs on the controller via an additional circuit to add this functionality. With that out of the way, they were ready to try out some games.
If you owned a classic Commodore home computer you might not have known it at the time, but it would have contained a versatile integrated circuit called the MOS6526. This so-called CIA chip, for Complex Interface Adaptor, contained parallel and serial ports, timers, and a time-of-day counter. Like so many similar pieces of classic silicon it’s long out of production, so [Daniel Molina] decided to replicate a modern version of it on a PCB using 74HGT CMOS logic.
The result will be a stack of boards board that appear to be about the size of a 3.5″ floppy disk covered in surface-mount 74 chips, and connected to the CIA socket of the Commodore by a ribbon cable. The base board is the only one completed so far and contains the data direction registers and parallel ports, but the succeding boards will each carry one of the chip’s other functions.
It seems rather odd to use so much silicon to recreate a single chip, but the point is not of course to provide a practical CIA replacement. Instead it’s instructive, it shows us how these interfaces work as well as just how much circuitry is crammed into the chip. It’s no surprise that it’s inspired by the C74 Project, a TTL 6502 processor that we featured last year.
When the Raspberry Pi 3 Model B+ was announced in March of 2018, one of its new features was the ability to be (more easily) powered via Power-over-Ethernet (PoE), with an official PoE HAT for the low price of just twenty-one USA bucks. The thing also almost worked as intended the first time around. But to some people this just isn’t good enough, resulting in [Albert David] putting out a solution he calls “poor man’s PoE” together for about two bucks.
His solution makes it extra cheap by using so-called passive PoE, which injects a voltage onto the conductors of the network cable being used for PoE, without bothering with any kind of handshake. In general this is considered to be a very reliable (albeit non-standard) form of PoE that works great until something goes up in smoke. It’s also ridiculously cheap, with a PoE injector adapter (RJ-45 plug & 2.1×5.5 mm power jack to RJ-45 jack) going for about 80 cents, and a DC-DC buck converter that can handle the input of 12V for about 50 cents.
The rest of the $2 budget is mostly spent on wiring and heatshrink, resulting in a very compact PoE solution that plugs straight into the PoE header on the Raspberry Pi 3 board, with the buck converter outputs going into the ground and +5V pins on the Raspberry Pi’s GPIO header.
A fancier solution would implement any of the standard PoE protocols to do the work of negotiating a suitable voltage. Maybe this could be the high-tech, $5 solution featuring an MCU and a small PCB?
We no longer use floppy disks on the vast majority of computers, but a recent Old New Thing blog post from Microsoft sheds light on one of their possible unexpected legacies. It seems Windows disk cache items expire after two seconds, and as the post explains this has its origin in the development of MS-DOS 2.0.
Disks, especially floppy disks, are slow compared to computer memory. A disk cache is a piece of memory into which the operating system puts frequently loaded items to speed up access and avoid its having to repeatedly access the disk. They have an expiry time to ensure that the cache doesn’t become clogged with data that hasn’t been needed for a while.
IBM PC floppy drives didn’t implement any form of notification for a disk eject, so it became quite possible for a disk to be ejected while the operating system still believed cached data from it to be valid. Thus a pair of Microsoft engineers tried their hardest to swap floppy discs as fast as they could, and it was discovered to be an impossible task in under two seconds. This became the cache expiry time for a Microsoft OS, and thus we’re told the floppy’s legacy lives on as more than just the ‘save’ icon.
As this is being written the Internet is abuzz with a viral Tweet about railroad gauges having an origin in the width of a Roman horse, that rail historians are debunking with a reference to the coal tramways of [George Stephenson’s] Northern England. It’s thus sometimes dangerous to take simple soundbite origin stories at face value, but since in this case our source is Microsoft themselves we think we can take it as being close to the horse’s mouth. Even if it isn’t a Roman horse.
Back in the good old days of carburetors and distributors, the game was all about busting door locks and hotwiring the ignition to boost a car. Technology rose up to combat this, you may remember the immobilizer systems that added a chip to the ignition key without which the vehicle could not be started. But alongside antitheft security advances, modern vehicles gained an array of electronic controls covering everything from the entertainment system to steering and brakes. Combine this with Bluetooth, WiFi, and cellular connectivity — it’s unlikely you can purchase a vehicle today without at least one of these built in — and the attack surface has grown far beyond the physical bounds of bumpers and crumple zones surrounding the driver.
Cyberattackers can now compromise vehicles from the comfort of their own homes. This can range from the mundane, like reading location data from the navigation system to more nefarious exploits capable of putting motorists at risk. It raises the question — what can be done to protect these vehicles from unscrupulous types? How can we give the user ultimate control over who has access to the data network that snakes throughout their vehicle? One possible solution I’m looking at today is the addition of internet killswitches.
The Scope of the Problem
As any hacker knows, a connected computer is a vulnerable computer. In vehicles, not only are the embedded systems connected to the internet, but they’re also capable of controlling vital safety systems. While many wrote off these concerns as unrealistic, the uncomfortable truth came home to roost in 2015. Security researchers [Charlie Miller] and [Chris Valasek] were able to remotely take control of a Jeep Cherokee, with just a laptop and a 3G data connection. The duo were able to scan the internet for further targets, and could even track various Chrysler automobiles around the country thanks to GPS and their in-dash entertainment systems.
While the hack was limited to Fiat-Chrysler automobiles fitted with Uconnect infotainment systems, it highlighted the broader risks to all connected vehicles. The fact that a hacker was able to remotely target a car over the internet, and interfere with the transmission, brakes, and other functions was a wake-up call for the industry. It made it clear to both automakers and the public that matters of cybersecurity are present on the open road.
A Potential Solution
Flawed code is everywhere, and it’s unrealistic to believe that automakers will ever be able to produce cars with zero vulnerabilities. While over-the-air updates and improved basic security practices will help stem the tide, there will always be the occasional zero-day exploit that sends everyone for a loop. For personal computers, this is considered an acceptable risk. However, a compromised car can put lives at stake. Additionally, while useful, an internet connection is not actually a requirement for a car to provide transportation.
Thus, a useful tool in defending against automotive cyberattacks could be a simple one — give the user the ability to disconnect the vehicle from the internet entirely. While this would shut down streaming radio services and certain other non-essential facilities, it would also make remote attacks impossible. All the tricky firmware hacks in the world are worth naught if you can’t make a connection to the vehicle to deliver the payload, after all.
In order to make this easy, vehicles could ship with an internet killswitch to shutdown all wireless and cellular communication to the vehicle’s systems. It would require a careful and considered design, and ideally would have a standardized form across manufacturers. Naturally, a concerted effort to educate the public in this device’s use would be required. Printing a small note in the back of a 200+ page manual simply won’t cut it.
The benefits of such a device would be manifold, covering concerns of both security and privacy. In the event that an exploit is used in the wild, it would allow users to continue safely driving their cars while waiting for a patch to become available. Compare this to the current status quo where anyone wanting to disable wireless connections to their vehicle would need to navigate software menus different for each make (and possibly model) of vehicle, or go truly old school and start pulling fuses.
Of course, there are potential drawbacks, too. Consumers are notoriously difficult to educate. It’s likely that many will inadvertently activate the switch, before rolling up to their dealership in a fury over their entertainment system which refuses to stream music, or fails to connect their phone for hands-free use. Any IT help desk worker will be familiar with the pain caused by hardware WiFi switches hidden on the sides of laptops, unbeknownst to hapless users. Additionally, if not placed in a clear and obvious location, or if the functionality is hidden deep in a menu system, many drivers will fail to use the system entirely.
Despite this, it seems crazy that modern connected vehicles don’t have a way to quickly and easily shut down their wireless connections. In the same way the Firestone tyre controversy led to tyre pressure monitors becoming mandatory, it may take a widespread controversy to push governments into action. Short of driving around with a cellular jammer, there seems little the average motorist can do to protect themselves against vehicular cyberattacks. If automakers are unable to protect consumers, we may see the community find their own solutions, even if it’s as simple as not paying their cellular service bills.
We’d like to hear what you have to say about. Do you think vehicles need a reliable way of toggling the data connections built into them? Is the automotive internet killswitch a reasonable option for mitigating exploits in automobiles or is it merely a bandage on a larger problem that’s not going away anytime soon? How do you think the average consumer would react to the appearance of an “internet off” button on the dashboard? Let us know what you think in the comments below.
One problem with ham radio these days is that most hams live where you can’t put a big old antenna up due to city laws and homeowner covenants. If you’re just working local stations on VHF or UHF, that might not be a big problem. But for HF usage, using a low profile antenna is a big deal. However, most modern radios can operate remotely. Well-known ham radio company MFJ now has the RigPi Station Server and [Ham Radio DX] has an early version and did a review.
As the name implies, the box contains a Raspberry Pi. There’s also an audio interface. The idea is to consolidate rig control along with other station control (such as rotators) along with feeding audio back and forth to the radio. It also sends Morse code keying to the radio. The idea is that this box will put your radio on the network so that you operate it using a web browser on a PC or a mobile device.
According to MFJ, you can operate voice, Morse code, or digital modes easily and remotely. The box uses open source software that can control over 200 different radios and 30 rotors. Of course, you could build all this yourself and use the same open source software, but it is nicely packaged. [Ham Radio DX] says you don’t need to know much about the Pi or Linux to use the box, although clearly you can get into Linux and use the normal applications if you’re so inclined.
Even if you don’t want to transmit, we could see a set up like this being used for remote monitoring. We’d like to see a companion box for the remote end that had the audio hardware, a keyer, and perhaps a knob to act as a remote control of sorts. Of course, you could probably figure out how to do that yourself. We wonder if some ham clubs might start offering a remote radio via an interface like this — we’ve seen it done before, but not well.
Your $50 radio probably isn’t going to work with this, and if you use FT8, you could argue you don’t need to be there anyway.