Reverse Engineering The Quansheng Hardware

In the world of cheap amateur radio transceivers, the Quansheng UV-K5 can’t be beaten for hackability. But pretty much every hack we’ve seen so far focuses on the firmware. What about the hardware?

To answer that question, [mentalDetector] enlisted the help of a few compatriots and vivisected a UV-K5 to find out what makes it tick. The result is a complete hardware description of the radio, including schematics, PCB design files, and 3D renders. The radio was a malfunctioning unit that was donated by collaborator [Manuel], who desoldered all the components and measured which ones he could to determine specific values. The parts that resisted his investigations got bundled up along with the stripped PCB to [mentalDetector], who used a NanoVNA to characterize them as well as possible. Documentation was up to collaborator [Ludwich], who also made tweaks to the schematic as it developed.

PCB reverse engineering was pretty intense. The front and back of the PCB — rev 1.4, for those playing along at home — were carefully photographed before getting the sandpaper treatment to reveal the inner two layers. The result was a series of high-resolution photos that were aligned to show which traces connected to which components or vias, which led to the finished schematics. There are still a few unknown components, The schematic has a few components crossed out, mostly capacitors by the look of it, representing unpopulated pads on the PCB.

Hats off to the team for the work here, which should make hardware hacks on the radio much easier. We’re looking forward to what’ll come from this effort. If you want to check out some of the firmware exploits that have already been accomplished on this radio, check out the Trojan Pong upgrade, or the possibilities of band expansion. We’ve also seen a mixed hardware-firmware upgrade that really shines.

Ancient Cable Modem Reveals Its RF Secrets

Most reverse engineering projects we see around here have some sort of practical endpoint in mind. Usually, but not always. Reverse-engineering a 40-year-old cable modem probably serves no practical end, except for the simple pleasure of understanding how 1980s tech worked.

You’ll be forgiven if the NABU Network, the source of the modem [Jared Boone] tears into, sounds unfamiliar; it only existed from 1982 to 1985 and primarily operated in Ottawa, Canada. It’s pretty interesting though, especially the Z80-based computer that was part of the package. The modem itself is a boxy affair bearing all the hallmarks of 1980s tech. [Jared]’s inspection revealed a power supply with a big transformer, a main logic board, and a mysterious shielded section with all the RF circuits, which is the focus of the video below.

Using a signal generator, a spectrum analyzer, and an oscilloscope, not to mention the PCB silkscreen and component markings, [Jared] built a block diagram of the circuit and determined the important frequencies for things like the local oscillator. He worked through the RF section, discovering what each compartment does, with the most interesting one probably being the quadrature demodulator. But things took a decidedly digital twist in the last compartment, where the modulated RF is turned into digital data with a couple of 7400-series chips, some comparators, and a crystal oscillator.

This tour of 80s tech and the methods [Jared] used to figure out what’s going on in this box were pretty impressive. There’s more to come on this project, including recreating the original signal with SDRs. In the mean time, if this put you in the mood for other videotext systems of the 80s, you might enjoy this Minitel terminal teardown.

Continue reading “Ancient Cable Modem Reveals Its RF Secrets”

Unraveling The Secrets Of Apple’s Mysterious Fisheye Format

Apple has developed a proprietary — even mysterious — “fisheye” projection format used for their immersive videos, such as those played back by the Apple Vision Pro. What’s the mystery? The fact that they stream their immersive content in this format but have provided no elaboration, no details, and no method for anyone else to produce or play back this format. It’s a completely undocumented format and Apple’s silence is deafening when it comes to requests for, well, anything to do with it whatsoever.

Probably those details are eventually forthcoming, but [Mike Swanson] isn’t satisfied to wait. He’s done his own digging into the format and while he hasn’t figured it out completely, he has learned quite a bit and written it all up on a blog post. Apple’s immersive videos have a lot in common with VR180 type videos, but under the hood there is more going on. Apple’s stream is DRM-protected, but there’s an unencrypted intro clip with logo that is streamed in the clear, and that’s what [Mike] has been focusing on.

Most “fisheye” formats are mapped onto square frames in a way similar to what’s seen here, but this is not what Apple is doing.

[Mike] has been able to determine that the format definitely differs from existing fisheye formats recorded by immersive cameras. First of all, the content is rotated 45 degrees. This spreads the horizon of the video across the diagonal, maximizing the number of pixels available in that direction (a trick that calls to mind the heads in home video recorders being tilted to increase the area of tape it can “see” beyond the physical width of the tape itself.) Doing this also spreads the center-vertical axis of the content across the other diagonal, with the same effect.

There’s more to it than just a 45-degree rotation, however. The rest most closely resembles radial stretching, a form of disc-to-square mapping. It’s close, but [Mike] can’t quite find a complete match for what exactly Apple is doing. Probably we’ll all learn more soon, but for now Apple isn’t saying much.

Videos like VR180 videos and Apple’s immersive format display stereoscopic video that allow a user to look around naturally in a scene. But to really deliver a deeper sense of presence and depth takes light fields.

Human-Interfacing Devices: HID Over I2C

In the previous two HID articles, we talked about stealing HID descriptors, learned about a number of cool tools you can use for HID hacking on Linux, and created a touchscreen device. This time, let’s talk about an underappreciated HID standard, but one that you might be using right now as you’re reading this article – I2C-HID, or HID over I2C.

HID as a protocol can be tunneled over many different channels. If you’ve used a Bluetooth keyboard, for instance, you’ve used tunneled HID. For about ten years now, I2C-HID has been heavily present in laptop space, it was initially used in touchpads, later in touchscreens, and now also in sensor hubs. Yes, you can expose sensor data over HID, and if you have a clamshell (foldable) laptop, that’s how the rotation-determining accelerometer exposes its data to your OS.

This capacitive touchscreen controller is not I2C-HID, even though it is I2C. By [Raymond Spekking], CC-BY-SA 4.0
Not every I2C-connected input device is I2C-HID. For instance, if you’ve seen older tablets with I2C-connected touchscreens, don’t get your hopes up, as they likely don’t use HID – it’s just a complex-ish I2C device, with enough proprietary registers and commands to drive you crazy even if your logic analysis skills are on point. I2C-HID is nowhere near that, and it’s also way better than PS/2 we used before – an x86-only interface with limited capabilities, already almost extinct from even x86 boards, and further threatened in this increasingly RISCy world. I2C-HID is low-power, especially compared to USB, as capable as HID goes, compatible with existing HID software, and ubiquitous enough that you surely already have an I2C port available on your SBC.

In modern world of input devices, I2C-HID is spreading, and the coolest thing is that it’s standardized. The standardization means a lot of great things for us hackers. For one, unlike all of those I2C touchscreen controllers, HID-I2C devices are easier to reuse; as much as information on them might be lacking at the moment, that’s what we’re combating right now as we speak! If you are using a recent laptop, the touchpad is most likely I2C-HID. Today, let’s take a look at converting one of those touchpads to USB HID.

A Hackable Platform

Continue reading “Human-Interfacing Devices: HID Over I2C”

Porting Modern Windows Applications To Windows 95

Windows 95 was an amazing operating system that would forever transform the world of home computing, setting the standard for user interaction on a desktop and quite possibly was the OS which had the longest queue of people lining up on launch day to snag a boxed copy. This raises the question of why we still don’t write software for this amazing OS, because ignoring the minor quibbles of ‘security patches’ and ‘modern hardware compatibility’, it’s still has pretty much the same Win32 API as supported in Windows 11, plus it doesn’t even spy on you, or show you ads. This line of reasoning led [MattKC] recently to look at easy ways to port modern applications to Windows 95.

In the video, the available options are ticked off, starting with straight Win32 API. Of course, nobody writes for the Win32 API for fun or to improve their mental well-being, and frameworks like WxWidgets and QuteQt have dropped support for Windows 9x and generally anything pre-Win2k for years now. The easiest option therefore might be Microsoft’s .NET framework, which in its (still supported) 2.0 iteration actually supports Windows 98 SE, or basically within spitting distance of running it on the original Win95.

Continue reading “Porting Modern Windows Applications To Windows 95”

How Star Trek Breached The Defences Of A Major Broadcaster

Back in 2020 in the brief lull between COVID lockdowns in the UK, I found myself abruptly on the move, with a very short time indeed to move my possessions into storage. As I was going through the accumulated electronic detritus of over four decades, I happened upon a grey box with some wires hanging out of it, and more than a few memories. This was a Sky VideoCrypt decoder, and the wires were part of the so-called “Season” interface to attach it to the serial port of a PC. It had this modification in the hope of catching some unauthorised free satellite TV, and in its day this particular hack caused some headaches for the broadcaster.

When More Than 4 Channels Was A Novelty

Patrick Stewart, as Captain Jean-Luc Picard. Composite image, via Wikimedia commons.
Break encryption? This man can make it so. Stefan Kühn, CC BY-SA 3.0.

In the 1980s and early 1990s, there was very little in the way of digital broadcasting on either satellites or terrestrial networks, almost everything on TV was sent out as standard definition analogue video. The four terrestrial channels where I grew up were all free-to-air, and if you had a satellite dish you could point it at any one of a variety of satellites and receive more free-to-air channels if you didn’t mind most of them being in German. Premium satellite programming was encrypted though, either through a range of proprietary analogue schemes, or for the British broadcaster Sky’s offering, through their VideoCrypt system. This used a 64 kB buffer to store each line of video, and rotate it round any one of 256 points along its length, resulting in an unintelligible picture.

Sky was the UK’s big gorilla of premium broadcasters, a role they kept for many years, and which was only eroded by the advent of streaming services. As such they snapped up exclusive first access to much of the most desirable content of the day, restricting it to only their British pay-to-subscribe customers. A viewer in the UK who grumbled about Star Trek Next Generation not being on the BBC could at least cough up for Sky, but if they didn’t have a British address they were out of luck. It was in this commercial decision, whether it was based upon business or on licensing, that Sky unwittingly sowed the seeds of Videocrypt’s demise.

 

Continue reading “How Star Trek Breached The Defences Of A Major Broadcaster”

The Intel 8088 And 8086 Processor’s Instruction Prefetch Circuitry

The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip's single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff)
The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip’s single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff)

Cache prefetching is what allows processors to have data and/or instructions ready for use in a fast local cache rather than having to wait for a fetch request to trickle through to system RAM and back again. The Intel 8088  (and its big brother 8086) processor was among the first microprocessors to implement (instruction) prefetching in hardware, which [Ken Shirriff] has analyzed based on die images of this famous processor. This follows last year’s deep-dive into the 8086’s prefetching hardware, with (unsurprisingly) many similarities between these two microprocessors, as well as a few differences that are mostly due to the 8088’s cut-down 8-bit data bus.

While the 8086 has 3 16-bit slots in the instruction prefetcher the 8088 gets 4 slots, each 8-bit. The prefetching hardware is part of the Bus Interface Unit (BIU), which effectively decouples the actual processor (Execution Unit, or EU) from the system RAM. While previous MPUs would be fully deterministic, with instructions being loaded from RAM and subsequently executed, the 8086 and 8088’s prefetching meant that such assumptions no longer were true. The added features in the BIU also meant that the instruction pointer (IP) and related registers moved to the BIU, while the ringbuffer logic around the queue had to somehow keep the queueing and pointer offsets into RAM working correctly.

Even though these days CPUs have much more complicated, multi-level caches that are measured in kilobytes and megabytes, it’s fascinating to see where it all began, with just a few bytes and relatively straight-forward hardware logic that you easily follow under a microscope.