The Headache Of Fake 74LS Logic Chips

November 4, 2025 by Maya Posch 21 Comments

When you go on your favorite cheap online shopping platform and order a batch of 74LS logic ICs, what do you get? Most likely relabeled 74HC ICs, if the results of an AliExpress order by [More Fun Fixing It] on YouTube are anything to judge by. Despite the claims made by the somewhat suspect markings on the ICs, even the cheap component tester used immediately identified them as 74HC parts.

Why is this a problem, you might ask? Simply put, 74LS are Low-power Schottky chips using TTL logic levels, whereas 74HC are High-Speed CMOS, using CMOS logic levels. If these faked chips had used 74HCT, they would have been compatible with TTL logic levels, but with the TTL vs CMOS levels mismatch of 74HC, you are asking for trouble.

CMOS typically requires that high levels are at least 70% of Vcc, and low to be at most 30% of Vcc, whereas TTL high level is somewhere above 2.0V. 74HC also cannot drive its outputs as strongly as 74LS, which opens another can of potential issues. Meanwhile HCT can be substituted for LS, but with the same lower drive current, which may or may not be an issue.

Interestingly, when the AliExpress seller was contacted with these findings, a refund was issued practically immediately. This makes one wonder why exactly faked 74LS ICs are even being sold, when they’d most likely be stuffed into old home computers by presumably hardware enthusiasts with a modicum of skill and knowledge.

Continue reading “The Headache Of Fake 74LS Logic Chips” →

Reproduced And Recovered: The First Chinese Keyboard-based MingKwai Typewriter

November 3, 2025 by Maya Posch 3 Comments

We all know what a typewriter looks like, and how this has been translated directly into the modern day computer keyboard, or at least many of us think we do. Many cultures do not use a writing system like the Roman or Cyrillic-style alphabets, with the Chinese writing system probably posing the biggest challenge. During the rise of mechanical typewriters, Chinese versions looked massive, clumsy and slow as they had to manage so many different symbols. All of them, except for one prototype of the MingKwai, which a group of Chinese enthusiasts have recently built themselves using the patent drawings.

Interestingly, when they started their build, it was thought that every single prototype of the MingKwai had been lost to time. That was before a genuine prototype was found in a basement in New York and acquired by Stanford University Libraries, creating the unique experience of being able to compare both a genuine prototype and a functional recreation.

Considered to be the first Chinese typewriter with a keyboard, the MingKwai (明快打字機, for ‘clear and fast’) was developed by [Lin Yutang] in the 1940s. Rather than the simple mechanism of Western typewriters where one key is linked directly to one hammer, the MingKwai instead uses the keys as a retrieval, or indexing mechanism.

Different rows select a different radical from one of the multiple rolls inside the machine, with a preview of multiple potential characters that these can combine to. After looking at these previews in the ‘magic eye’ glass, you select the number of the target symbol. In the video by the Chinese team this can be seen in action.

Although [Lin]’s MingKwai typewriter did not reach commercialization, it offered the first glimpse of a viable Chinese input method prior to computer technology. These days the popular pinyin uses the romanized writing form, which makes it somewhat similar to the standard Japanese input method using its phonetic kana system of characters. Without such options and within the confined system of 1940s electromechanical systems, however, the MingKwai is both an absolute marvel of ingenuity, and absolutely mindboggling even by 2020s standards.

Continue reading “Reproduced And Recovered: The First Chinese Keyboard-based MingKwai Typewriter” →

Repurposing Dodgy Android TV Boxes As Linux Boxes

November 3, 2025 by Maya Posch 46 Comments

Marketplaces and e-waste recycling centers are practically overflowing with the things: ARM-based streaming TV boxes that run some — usually very outdated and compromised — version of Android. While you can use them for their promised streaming purposes, they’re invariably poorly optimized and often lie about their true hardware specifications. Which leaves the most important question: can you install Linux on these SBCs and use them as a poor man’s Raspberry Pi alternative? The answer, according to [Oleksii’s Tech] on YouTube is ‘sorta’.

The fake H313 TV box SBC in all its glory. (Credit: Oleksii's Tech, YouTube) — The fake H313 TV box SBC in all its glory. (Credit: Oleksii’s Tech, YouTube)

The commonly seen X96Q clone Android TV box that [Oleksii] bought for $10 is a good example. The clone advertises itself as based on a quad-core Cortex-A53 AllWinner H313 SoC, like the genuine X96Q, but actually has a Rockchip RK3229 inside with correspondingly far lower performance. After you have determined what the actual hardware inside the box is, you can get a copy of Armbian for that particular SoC. Here, the Rk322x-box minimal image was used, with the box booting straight off an SD card. Some Android TV boxes require much more complicated methods to even boot off external media, so this was a lucky break.

Continuing the hardware scam, it was advertised as having 2 GB of RAM and 16 GB of Flash, but it actually has just 1 GB of RAM and 8 GB of eMMC Flash. This was enough to get Armbian desktop up and running, but that’s about all you can do. Desktop application performance was atrocious, mostly due to the CPU’s quad Cortex-A7 cores struggling to keep up.

As also suggested in the comments, the best use for these low-spec SBCs is probably to run light server applications on them, including Pi-Hole, Samba, an IRC bouncer, and so on. They’re pretty low-power, often have the requisite Ethernet built in, and it keeps another bit of potential e-waste from getting scrapped.

Continue reading “Repurposing Dodgy Android TV Boxes As Linux Boxes” →

Building A PV Solar-Powered Quadcopter

November 1, 2025 by Maya Posch 72 Comments

The solar-powered quadcopter from below. (Credit: Luke Maximo Bell)

One of the most frustrating parts about flying a quadcopter is having to regularly swap battery packs, as this massively limits what you can do with said quadcopter, never mind its effective range. Obviously, having the sun power said quadcopter during a nice sunny day would be a much better experience, but how workable is this really? While airplanes have used solar power to stay aloft practically indefinitely, a quadcopter needs significantly more power, so is it even possible? Recently, [Luke Maximo Bell] set out to give it a whirl.

His quadcopter build uses a large but very lightweight carbon fiber frame, with large 18″ propellers. This provides the required space and lift for the solar panel array, which uses 27 razor-thin panels in a 9×3 grid configuration supported by a lightweight support frame.

Due to the lightweight construction, the resulting quadcopter actually managed to fly using just the direct power from the panels. It should be noted however that it is an exceedingly fragile design, to the point that [Luke]’s cat broke a panel in the array when walking over it while it was lying upside-down on a table.

After this proof of concept, [Luke] intends to add more panels, as well as a battery to provide some buffer and autonomous flying hardware, with the goal of challenging the world record for the longest flying drone. For the rest of us, this might make for a pretty cool idea for a LoRaWAN mesh node or similar, where altitude and endurance would make for a great combo.

Continue reading “Building A PV Solar-Powered Quadcopter” →

Making YouTube Work In The Netscape 4.5 Browser On Windows 98

October 31, 2025 by Maya Posch 14 Comments

The World Wide Web of the 90s was a magical place, where you couldn’t click two links without getting bombarded with phrases such as the Information Super Highway and Multimedia Experience. Of course, the multimedia experience you got on your Windows 9x PC was mostly limited to low-res, stuttery RealMedia and Windows video format clips, but what if you could experience YouTube back then, on your ‘multimedia-ready’ Celeron PC, running Netscape 4.5?

Cue the [Throaty Mumbo] bloke over on that very same YouTube, and his quest to make this dream come true. Although somewhat ridiculous on the face of it, the biggest problem is actually the era-appropriate hardware, as it was never meant to decode and display full-HD VP9-encoded videos.

Because the HTTPS requirement has meant that no 1990s or early 2000s browser will ever browse the modern WWW, a proxy was going to be needed no matter what. This Python-based proxy then got kitted out with not just the means to render down the convoluted HTML-CSS-JS mess of a YouTube page into something that a civilized browser can display, but also to fetch YouTube videos with yt-dlp and transcode it into MPEG1 in glorious SD quality for streaming to Netscape on the Windows 98 PC.

Because the same civilized browsers also support plugins, such as Netscape’s NPAPI, this meant that decoding and rendering the video was the easy part, as the browser just had to load the plugin and the latter doing all the heavy lifting. Perhaps unsurprisingly, with some tweaks even Netscape 2.0 can be used to browse YouTube and play back videos this way, with fullscreen playback and seeking support.

Although these days only a rare few modern browsers like Pale Moon still support NPAPI, it’s easy to see how the introduction of browser plugins boosted the multimedia future of the WWW that we find ourselves in today.

Continue reading “Making YouTube Work In The Netscape 4.5 Browser On Windows 98” →

North American Common Raven (Corvus corax principalis) in flight at Muir Beach in Northern California

PhantomRaven Attack Exploits NPM’s Unchecked HTTP URL Dependency Feature

October 30, 2025 by Maya Posch 14 Comments

An example of RDD in a package's dependencies list. It's not even counted as a 'real' dependency. (Credit: Koi.ai) — An example of RDD in a package’s dependencies list. It’s not even counted as a ‘real’ dependency. (Credit: Koi.ai)

Having another security threat emanating from Node.js’ Node Package Manager (NPM) feels like a weekly event at this point, but this newly discovered one is among the more refined. It exploits not only the remote dynamic dependencies (RDD) ‘feature’ in NPM, but also uses the increased occurrence of LLM-generated non-existent package names to its advantage. Called ‘slopsquatting’, it’s only the first step in this attack that the researchers over at [Koi] stumbled over by accident.

Calling it the PhantomRaven attack for that cool vibe, they found that it had started in August of 2025, with some malicious packages detected and removed by NPM, but eighty subsequent packages evaded detection. A property of these packages is that in their dependencies list they use RDD to download malicious code from a HTTP URL. It was this traffic to the same HTTP domain that tipped off the researchers.

For some incomprehensible reason, allowing these HTTP URLs as package dependency is an integral part of the RDD feature. Since the malicious URL is not found in the code itself, it will slip by security scanners, nor is the download cached, giving the attackers significantly more control. This fake dependency is run automatically, without user interaction or notification that it has now begun to scan the filesystem for credentials and anything else of use.

The names of the fake packages were also chosen specifically to match incomplete package names that an LLM might spit out, such as unused-import instead of the full package name of eslint-plugin-unused-imports as example. This serves to highlight why you should not only strictly validate direct dependencies, but also their dependencies. As for why RDD is even a thing, this is something that NPM will hopefully explain soon.

Top image: North American Common Raven (Corvus corax principalis) in flight at Muir Beach in Northern California (Credit: Copetersen, Wikimedia)

Self-Driving Cars And The Fight Over The Necessity Of Lidar

October 30, 2025 by Maya Posch 72 Comments

If you haven’t lived underneath a rock for the past decade or so, you will have seen a lot of arguing in the media by prominent figures and their respective fanbases about what the right sensor package is for autonomous vehicles, or ‘self-driving cars’ in popular parlance. As the task here is to effectively replicate what is achieved by the human Mark 1 eyeball and associated processing hardware in the evolutionary layers of patched-together wetware (‘human brain’), it might seem tempting to think that a bunch of modern RGB cameras and a zippy computer system could do the same vision task quite easily.

This is where reality throws a couple of curveballs. Although RGB cameras lack the evolutionary glitches like an inverted image sensor and a big dead spot where the optical nerve punches through said sensor layer, it turns out that the preprocessing performed in the retina, the processing in the visual cortex and analysis in the rest of the brain is really quite good at detecting objects, no doubt helped by millions of years of only those who managed to not get eaten by predators procreating in significant numbers.

Hence the solution of sticking something like a Lidar scanner on a car makes a lot of sense. Not only does this provide advanced details on one’s surroundings, but also isn’t bothered by rain and fog the way an RGB camera is. Having more and better quality information makes subsequent processing easier and more effective, or so it would seem.

Continue reading “Self-Driving Cars And The Fight Over The Necessity Of Lidar” →