For those who have a passion for vintage hardware, whether it be a classic computer or a war-surplus ham radio rig, finding the things without resorting to paying shipping fees on eBay can sometimes be tricky. Your best bet is to find a local fair or swap event, but it always seems they’re the kind of thing you find out about the weekend after they were held.
Anyone who was lucky enough to secure a Gmail invite back in early 2004 would have gasped in wonder at the storage on offer, a whole gigabyte! Nearly two decades later there’s more storage to be had for free from Google and its competitors, but it’s still relatively easy to hit the paid tier. Consider this though, how about YouTube as an infinite cloud storage medium?
The proof of concept code from [DvorakDwarf] works by encoding binary files into video files which can then be uploaded to the video sharing service. It’s hardly a new idea as there were clever boxes back in the 16-bit era that would do the same with a VHS video recorder, but it seems that for the moment it does what it says, and turns YouTube into an infinite cloud file store.
The README goes into a bit of detail about how the code tries to avoid the effects of YouTube’s compression algorithm. It eschews RGB colour for black and white pixels, and each displayed pixel in the video is made of a block of the real pixels. The final video comes in at around four times the size of the original file, and looks like noise on the screen. There’s an example video, which we’ve placed below the break.
Whether this is against YouTube’s TOS is probably open for interpretation, but we’re guessing that the video site could spot these uploads with relative ease and apply a stronger compression algorithm which would corrupt them. As an alternate approach, we recommend hiding all your important data in podcast episodes.
We live in a time when having an oscilloscope is only a minor luxury. But for many decades, a good scope was a major expense, and almost no hobbyist had a brand new one unless it was of very poor quality. Scopes were big and heavy and, at the price most people were willing to pay, only had a single channel. Granted, having one channel is better than having nothing. But if the relative benefit of having a single channel scope is 10 points, the benefit of having two channels is easily at least 100 points. So what was a poor hacker to do when a dual-trace or higher scope cost too much? Why, hack, of course. There were many designs that would convert a single trace scope into a poor-quality multichannel scope. Heathkit made several of these over the years like the ID-22, the ID-101, and the ID-4101. They called them “electronic switches.” The S-2 and S-3 were even earlier models, but the idea wasn’t unique to Heathkit and had been around for some time.
For $25, you could change your scope to dual trace!
There were two common approaches. With alternative or alt mode, you could trigger a sync pulse and draw one trace. Then trigger again and draw the second trace with a fixed voltage offset. If you do this fast enough, it looks like there are two traces on the screen at one time. The other way is to rapidly switch between voltages during the sweep and use the scope’s Z input to blank the trace when it is between signals. This requires a Z input, of course, and a fast switching clock. This is sometimes called “chopper mode” or, simply, chop. This wasn’t just the realm of adapters, though. Even “real” analog scopes that did dual channels used the same methods, although generally with the benefit of being integrated with the scope’s electronics.
[Machining and Microwaves] has long wanted to use a 3D printer to print RF components for antennas and microwave lenses. He heard that Rogers — the company known for making PCB substrates, among other things — had a dielectric resin available and asked them if he could try some. They agreed, with some stipulations, including that he had to visit their facility and show his designs in a video. Because of that, the video seems a little bit like a commercial, but we think he is genuinely excited about the possibility of the resin.
Since he was in their facility, he was able to interview several of the people behind the resin, and they had some interesting observations about keeping resin consistent during printing and how the moonbounce feed he wanted to print would work.
Some of the exotic RF test equipment was interesting to see, too. The microwave lenses look like some kind of modern art. According to the Roger’s website:
Radix Printable Dielectric materials are a ceramic-filled, UV-curable polymer designed for use with photopolymer 3D-printing processes like sterolithography (SLA) and digital light processing (DLP) printing. These materials and printing processes enable the use of high-resolution, scalable 3D-printing for complex RF dielectric components such as gradient index (GRIN) lenses or three-dimensional circuits. The 2.8Dk printable dielectric is designed to have low loss characteristics through millimeter wave (mmWave) frequencies and low moisture absorption for end-use applications.
It isn’t clear to us that you could use this resin in your own printers, but they did look pretty similar to what we have hanging around except, perhaps, for the continuous circulation of the resin pool. We figured the resin wasn’t inexpensive. In fact, we found a liter online for $1,863. We don’t know if that’s the suggested retail price or not, but we also suppose if you need this material, you won’t be that surprised at the cost.
[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding. (Slides here, PDF.)
There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.
The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.
[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!
It’s fair to say that among the new product launches we see all the time, anything new from the folks at Raspberry Pi claims our attention. It’s not that their signature Linux single-board computers (SBCs) are necessarily the best or the fastest hardware on paper, but that they’re the ones with meaningful decade-plus support. Add to that their RP2040 microcontroller and its associated Pico boards, and they’re the one to watch.
Today we’ve got news of a new Pi, not a general purpose computer, but useful nevertheless. The Raspberry Pi Debug Probe is a small RP2040-based board that provides a SWD interface for debugging any ARM microcontroller as well as a more generic USB to UART interface.
The article sums up nicely what this board does — it’s for bare metal ARM coders, and it uses ARM’s built-in debugging infrastructure. It’s something that away from Hackaday we’ve seen friends using the 2040 for as one of the few readily available chips in the shortage, and it’s thus extremely convenient to have readily available as a product.
So if you’re a high level programmer it’s not essential, but if you’re really getting down to the nuts-and-bolts of an ARM microcontroller then you’ll want one of these. Of course, it’s by no means the first SWD interface we’ve seen, here’s one using an ESP32.
An article on the history of EPROMs in the Soviet Union by [Vladimir Yakovlev] over at The CPU Shack Museum caught our attention. It is part one of a series on the topic, and walks you through the earliest Soviet EPROMs families.
Early EPROM programmer using punched paper tape (Intel, Electronics Magazine 1971)
The first of which, from the 1970s, is the K505RR1 developed and manufactured in Kyiv, equivalent to the first-generation Intel 1702A. It could hold 2048 bits, organized as 256×8, and offered a whopping 20 reprogramming cycles and data retention of 5000 hours.
The narrative proceeds to introduce several subsequent generations, design facilities, manufacturing techniques, and representative chip examples. A few tidbits — unlike Western EPROMs, the Soviets managed to put quartz windows in plastic packages (see the KP573 family).
In addition to the common gray or white, they also used different terracotta colored ceramic packages. An odd ceramic flat-pack EPROM is shown, and also some EPROMs whose dies have been painted over and re-badged as OTP chips.
Intel began producing EPROMs in 1971 as reported by the inventor, Intel’s Dov Frohman-Bentchkowsky, in Electronics Magazine’s 10 May edition (pg 91). We learned, amongst other things, that the 1701 did not have a quartz window, but could still be erased by exposure to X-rays. A friendly word of warning — browsing electronics advertisements from 50 years ago can easily consume your entire morning.
Once the package is sealed, information can still be erased by exposing it to X radiation in excess of 5×104 rads, a dose which is easily attainable with commercial X-ray generators.
