Remote Code Execution On An Oscilloscope

There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.

The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.

In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.

Discussing The Finer Points Of Space-Worthy Software

At the dawn of the Space Race, when computers were something that took up whole rooms, satellites and probes had to rely on analog electronics to read from their various sensors and transmit the resulting data to the ground. But it wasn’t long before humanity’s space ambitions outgrew these early systems, which lead to vast advancements in space-bound digital computers in support of NASA’s Gemini and Apollo programs. Today, building a spacecraft without an onboard computer (or even multiple redundant computers) is unheard of. Even the smallest of CubeSats is likely running Linux on a multi-core system.

Jacob Killelea

As such, software development has now become part an integral part of spacecraft design — from low-level code that’s responsible for firing off emergency systems to the 3D graphical touchscreen interfaces used by the crew to navigate the craft. But as you might expect, the stakes here are higher than any normal programming assignment. If your code locks up here on Earth, it’s an annoyance. If it locks up on a lunar lander seconds before it touches down on the surface, it could be the end of the mission.

To get a bit more insight into this fascinating corner of software development, we invited Jacob Killelea to host last week’s
Software for Satellites Hack Chat. Jacob is an engineer with a background in both aero and thermodynamics, control systems, and life support. He’s written code for spacecraft destined for the Moon, and perhaps most importantly, is an avid reader of Hackaday.

Continue reading “Discussing The Finer Points Of Space-Worthy Software”

Adapter Board Expands The Pi Zero

The standard Raspberry Pi computers have been in short supply for a while now, so much so that people are going to great lengths to find replacements. Whether it’s migrating to alternative single-board computers or finding clones of the Pi that are “close enough”, there are solutions out there. This method of building a full-size Raspberry Pi with all of the bells and whistles using the much-less-in-demand Pi Zero also stands out as a clever solution.

[SpookyGhost] didn’t build this one himself, but he did stumble across it and write a pretty extensive how-to and performance evaluation for the board, which can be found here. The adapter connects to the Zero’s HDMI and USB ports, and provides all the connectors you’d expect from a larger Pi such as the 3B. It’s not a perfect drop-in replacement though — you don’t get the 3.5 mm audio jack, and the micro SD card location doesn’t match up with where it should be on a “real” Pi.

All things considered, this is one of those solutions that seems obvious in retrospect but we still appreciate its elegance. It might disappear as soon as chip shortages stop being an issue, but for now we’ll take any solutions we can. If you don’t already have a Pi Zero on hand, we’ve seen some other successes replacing them with thin clients or even old smartphones.

DisplayPort: Under The Hood

Last time, we looked at all the things that make DisplayPort unique for its users. What about the things that make it unique for hackers? Let’s get into all the ways that DisplayPort can serve you on your modern tech wrangling adventures.

You Are Watching The AUX Channel

With DisplayPort, the I2C bus we’ve always seen come bundled with VGA, DVI and HDMI, is no more – it’s been replaced by the AUX bus. AUX is a 1 MHz bidirectional diffpair – just a bit too complex for a cheap logic analyzer, though, possibly, something you could wrangle with the RP2040’s PIOs. Hacking thoughts aside, it’s a transparent replacement for I2C, so that software doesn’t have to be rewritten – for instance, it usually does I2C device passthrough over AUX, so that EDID data can still be stored in a separate EEPROM chip on the monitor or eDP LCD panel.

AUX isn’t just a differential bus, it’s more pseudodifferential, like USB2 – for instance, AUX_P and AUX_N are used separately, with a combination of 1 MΩ and 100 kΩ pullups and pulldowns signaling different states of the physical connection – for instance, a pullup on AUX+ and a pulldown on AUX- means that an external device has been connected. If you’d like to learn which combination of resistors means what, you can find in the DisplayPort specification, which isn’t distributed openly but isn’t hard to come by, either.

Also, DisplayPort link training happens over AUX, and in order to facilitate that, a piece of DisplayPort controller’s external memory is usually exposed over the AUX channel, through a mechanism that’s called DPCD. If you dig a bit, using “DPCD” as the keyword, you can easily reach into the lower-level details of your DisplayPort connection. Some of the DPCD memory map is static, and some parts are FIFOs you can funnel data into, or out of. You can find a wide variety of documents online which describe the DPCD structure – for now, here’s a piece of Bash that works on Linux graphics drivers for AMD and Intel, and will show you you the first 16 bytes of DPCD:

# sudo dd if=/dev/drm_dp_aux0 bs=1 skip=256 count=16 |xxd
00000000: 0084 0000 0000 0000 0108 0000 0000 0000 ................
[...]

In particular, the 4th nibble (digit) here describes the amount of lanes for the DisplayPort link established – as you can see, my laptop uses a four-lane link. Also, the /dev/drm_dp_aux0 path might need to be adjusted for your device. In case you ever want to debug your DP link, having direct access to the DPCD memory space like this might help you quite a bit! For now, let’s move onto other practical aspects. Continue reading “DisplayPort: Under The Hood”

Finding Undocumented 8086 Instructions Via Microcode

Video gamers know about cheat codes, but assembly language programmers are often in search of undocumented instructions. One way to find them is to map out all of a CPU’s opcodes and where there are holes, try those values, and see what happens. Not good enough for [Ken Shirriff]. He prefers examining the CPU’s microcode and deducing what each part of it does.

Microcode is a feature of many modern CPUs. The CPU runs several “microcode” instructions to process a single opcode. For the Intel 8086, there are 512 micro instructions, each with 21 bits. Each instruction has two parts: a part that moves a source to a destination and another that performs some other operation, such as an ALU operation. [Ken] explains it all in the post, including several hidden registers you can’t see, but the microcode can.

Searching for holes in the opcode table.

Some of the undocumented instructions are probably not useful. They are either impractical or duplicate a function you can already do another way. Not all of the instructions are there for technical reasons. For example, opcode D6, commonly known as SALC for “Set AL to Carry”, seems to exist only as a trap for anyone making a carbon copy of Intel’s microcode. When other companies like NEC made 8086 clones, having an undocumented instruction would strongly suggest they just copied Intel’s intellectual property (in NECs case, they didn’t).

Other cases happen where an instruction just doesn’t make sense. For example, you can pop all segment registers, and though it is not documented, you can deduce that POP CS should be opcode 0F. The problem is there is no sane reason to pop CS off the stack. The instruction works; it just isn’t useful. The opcodes from 60-6F are conditional jumps that are no different from the instructions at 70-7F because of decoding. There is no reason to document both identical instruction ranges.

The plot thickens when you go to two-byte instructions. You’ll find plenty of instructions of dubious value. You don’t hear much about undocumented instructions anymore. Why? Because modern CPUs have enough circuitry to dedicate some to detecting illegal instructions and halting the CPU. But the 8086 was squeezed too tight to allow for such a luxury. Good thing for people like us who enjoy solving puzzles.

You can still get a modern CPU to tell you more about instructions even if it won’t run them. Even the 80286 had some secret opcodes.

DIY Laser For Ablating Metal

For those who wish to go beyond through-hole construction on perfboard for their circuit boards, a printed circuit board is usually the next step up. Allowing for things like surface-mount components, multi-layer boards, and a wider array of parts, they are much more versatile but do have a slight downside in that they are a little bit harder to make. There are lots of methods for producing them at home or makerspace, though, and although we’ve seen plenty of methods for their production like toner transfer, photoresist, and CNC milling, it’s also possible to make them using laser ablation, although you do need a special laser to get this job done.

The problem with cutting copper is that it reflects infra-red, so a higher-wavelength blue green laser is used instead. And because you want to ablate the copper, but not melt the surrounding areas or cut straight through the board, extremely short, high-power pulses are the way to go. Here, the [Munich Fab Lab] is using 9 kW pulses of around 30 microseconds each.  With these specifications the copper is ablated from the surface of the board allowing for fine details in the range of about 20 µm, which is fine enough for just about any circuit board. The design of the laser head itself is worth a look.

Aside from the laser, the rest is standard CNC machine fodder, but with an emphasis on safety that’s appropriate for a tool in a shared workspace, and the whole project is published under an open license and offers an affordable solution for larger-scale PCB production with extremely fine resolution and without the need for any amounts of chemicals for the more common PCB production methods. There is a lot more information available on the project’s webpage and its GitHub page as well.

Of course, there are other methods of producing PCBs by laser if you happen to have a 20 W fiber laser just kicking around.

Illumos Gets A New C Compiler

Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.

PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:

It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris

Continue reading “Illumos Gets A New C Compiler”