Open Source Hiding In Plain Sight

On the podcast, [Tom] and I were talking about the continuing saga of the libogc debacle. [Tom] has been interviewing some of the principals involved, so he’s got some first-hand perspective on it all – you should really go read his pieces. But the short version is that an old library that many Nintendo game emulators use appears to have cribbed code from both and open-source real-time operating system called RTEMS, and the Linux kernel itself.

You probably know Linux, but RTEMS is a high-reliability RTOS for aerospace. People in the field tell me that it’s well-known in those circles, but it doesn’t have a high profile in the hacker world. Still, satellites run RTEMS, so it’s probably also a good place to draw inspiration from, or simply use the library as-is. Since it’s BSD-licensed, you can also borrow entire functions wholesale if you attribute them properly.

In the end, an RTOS is an RTOS. It doesn’t matter if it’s developed for blinking LEDs or for guiding ICBMs. This thought got [Tom] and I to thinking about what other high-reliability open-source code is out there, hidden away in obscurity because of the industry that it was developed for. NASA’s core flight system came instantly to mind, but NASA makes much of its code available for you to use if you’re interested. There are surely worse places to draw inspiration!

What other off-the-beaten-path software sources do you know of that might be useful for our crowd?

ChatGPT & Me. ChatGPT Is Me!

For a while now part of my email signature has been a quote from a Hackaday commenter insinuating that an article I wrote was created by a “Dumb AI”. You have my sincerest promise that I am a humble meatbag scribe just like the rest of you, indeed one currently nursing a sore shoulder due to a sporting injury, so I found the comment funny in a way its writer probably didn’t intend. Like many in tech, I maintain a skepticism about the future role of large-language-model generative AI, and have resisted the urge to drink the Kool-Aid you will see liberally flowing at the moment.

Hackaday Is Part Of The Machine

As you’ll no doubt be aware, these large language models work by gathering a vast corpus of text, and doing their computational tricks to generate their output by inferring from that data. They can thus create an artwork in the style of a painter who receives no reward for the image, or a book in the voice of an author who may be struggling to make ends meet. From the viewpoint of content creators and intellectual property owners, it’s theft on a grand scale, and you’ll find plenty of legal battles seeking to establish the boundaries of the field.

Anyway, once an LLM has enough text from a particular source, it can do a pretty good job of writing in that style. ChatGPT for example has doubtless crawled the whole of Hackaday, and since I’ve written thousands of articles in my nearly a decade here, it’s got a significant corpus of my work. Could it write in my style? As it turns out, yes it can, but not exactly. I set out to test its forging skill. Continue reading “ChatGPT & Me. ChatGPT Is Me!”

Hackaday Podcast Episode 321: Learn You Some 3DP, Let The Wookie Win, Or Design A Thinkpad Motherboard Anew

Join Hackaday Editors Elliot Williams and Tom Nardi as they take a whirlwind tour of the best and brightest hacks of the last week. This episode starts off with an update about that Soviet Venus lander that’s been buzzing the planet, then moves on to best practices for designing 3D printed parts, giving Chrome OS devices a new lease on life, and a unique display technology that brings a Star Wars prop to life.

You’ll also hear about designing new motherboards for beloved old computers, why you might want to put your calipers on a flatbed scanner, and a NASA science satellite that’s putting in double duty as a wartime reporter. Finally, they’ll cover the interesting physics of meteor burst communications, and the latest developments in the ongoing libogc license kerfuffle.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download in DRM-free MP3.

Continue reading “Hackaday Podcast Episode 321: Learn You Some 3DP, Let The Wookie Win, Or Design A Thinkpad Motherboard Anew”

This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio

Spectre lives. We’ve got two separate pieces of research, each finding new processor primitives that allow Spectre-style memory leaks. Before we dive into the details of the new techniques, let’s quickly remind ourselves what Spectre is. Modern CPUs use a variety of clever tricks to execute code faster, and one of the stumbling blocks is memory latency. When a program reaches a branch in execution, the program will proceed in one of two possible directions, and it’s often a value from memory that determines which branch is taken. Rather than wait for the memory to be fetched, modern CPUs will predict which branch execution will take, and speculatively execute the code down that branch. Once the memory is fetched and the branch is properly evaluated, the speculatively executed code is rewound if the guess was wrong, or made authoritative if the guess was correct. Spectre is the realization that incorrect branch prediction can change the contents of the CPU cache, and those changes can be detected through cache timing measurements. The end result is that arbitrary system memory can be leaked from a low privileged or even sandboxed user process.

In response to Spectre, OS developers and CPU designers have added domain isolation protections, that prevent branch prediction poisoning in an attack process from affecting the branch prediction in the kernel or another process. Training Solo is the clever idea from VUSec that branch prediction poisoning could just be done from within the kernel space, and avoid any domain switching at all. That can be done through cBPF, the classic Berkeley Packet Filter (BPF) kernel VM. By default, all users on a Linux system can run cBPF code, throwing the doors back open for Spectre shenanigans. There’s also an address collision attack where an unrelated branch can be used to train a target branch. Researchers also discovered a pair of CVEs in Intel’s CPUs, where prediction training was broken in specific cases, allowing for a wild 17 kB/sec memory leak.

Continue reading “This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio”

Remembering More Memory: XMS And A Real Hack

Last time we talked about how the original PC has a limit of 640 kB for your programs and 1 MB in total. But of course those restrictions chafed. People demanded more memory, and there were workarounds to provide it.

However, the workarounds were made to primarily work with the old 8088 CPU. Expanded memory (EMS) swapped pages of memory into page frames that lived above the 640 kB line (but below 1 MB). The system would work with newer CPUs, but those newer CPUs could already address more memory. That led to new standards, workarounds, and even a classic hack.

XMS

If you had an 80286 or above, you might be better off using extended memory (XMS). This took advantage of the fact that the CPU could address more memory. You didn’t need a special board to load 4MB of RAM into an 80286-based PC. You just couldn’t get to with MSDOS. In particular, the memory above 1 MB was — in theory — inaccessible to real-mode programs like MSDOS.

Well, that’s not strictly true in two cases. One, you’ll see in a minute. The other case is because of the overlapping memory segments on an 8088, or in real mode on later processors. Address FFFF:000F was the top of the 1 MB range.

PCs with more than 20 bits of address space ran into problems since some programs “knew” that memory access above that would wrap around. That is FFFF:0010, on an 8088, is the same as 0000:0000. They would block A20, the 21st address bit, by default. However, you could turn that block off in software, although exactly how that worked varied by the type of motherboard — yet another complication.

XMS allowed MSDOS programs to allocate and free blocks of memory that were above the 1 MB line and map them into that special area above FFFF:0010, the so-called high memory area (HMA). Continue reading “Remembering More Memory: XMS And A Real Hack”

Remembering Memory: EMS, And TSRs

You often hear that Bill Gates once proclaimed, “640 kB is enough for anyone,” but, apparently, that’s a myth — he never said it. On the other hand, early PCs did have that limit, and, at first, that limit was mostly theoretical.

After all, earlier computers often topped out at 64 kB or less, or — if you had some fancy bank switching — maybe 128 kB. It was hard to justify the cost, though. Before long, though, 640 kB became a limit, and the industry found workarounds. Mercifully, the need for these eventually evaporated, but for a number of years, they were a part of configuring and using a PC.

Why 640 kB?

The original IBM PC sported an Intel 8088 processor. This was essentially an 8086 16-bit processor with an 8-bit external data bus. This allowed for cheaper computers, but both chips had a strange memory addressing scheme and could access up to 1 MB of memory.

In fact, the 8088 instructions could only address 64 kB, very much like the old 8080 and Z80 computers. What made things different is that they included a number of 16-bit segment registers. This was almost like bank switching. The 1 MB space could be used 64 kB at a time on 16-byte boundaries.

So a full address was a 16-bit segment and a 16-bit offset. Segment 0x600D, offset 0xF00D would be written as 600D:F00D. Because each segment started 16-bytes after the previous one, 0000:0020, 0001:0010, and 0002:0000 were all the same memory location. Confused? Yeah, you aren’t the only one.

Continue reading “Remembering Memory: EMS, And TSRs”

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The MingKwai Typewriter

Sometimes, a little goes a long way. I believe that’s the case with this tiny media control bar from [likeablob] that uses an ESP32-C3 Super Mini.

An in-line media control bar with four purple-capped key switch buttons and a knob.
Image by [likeablob] via Hackaday.IO
From left to right you’ve got a meta key that allows double functions for all the other keys. The base functions are play/pause, previous track, and next track while the knob handles volume.

And because it uses this Wi-Fi-enabled microcontroller, it can seamlessly integrate with Home Assistant via ESPHome.

What else is under the hood? Four low-profile Cherry MX Browns and a rotary encoder underneath that nicely-printed knob.

If you want to build one of these for yourself, all the files are available on GitHub including the customizable enclosure which [likeablob] designed with OpenSCAD. Continue reading “Keebin’ With Kristina: The One With The MingKwai Typewriter”