End-Of-Life For Z80 CPU And Peripherals Announced

In a Product Change Notification (PCN) published on April 15, Zilog (now owned by Littelfuse) announced the End of Life for a range of Z80 products, specifically virtually all of the Z84C00 range. This also includes the peripherals, such as the Z84C10 range of MPUs. These are currently already marked as EoL on stores like Mouser, with Littelfuse noting that the last orders with them can be placed until June 14th of 2024. After that you’ll have to try your luck with shady EBay sellers and a lucky box of old-new-stock found in the back of a warehouse.

What this effectively means is that after just under 48 years since its launch in 1976, the Zilog Z80 will no longer be available for sale as discrete components, which is likely to primarily impact hobbyists and people who are trying to keep retro systems going. This does not mean that it’s the end of the road for Z80, however, as the eZ80 will be produced for the foreseeable future.

These new chips will of course not come in easy to drop in DIPs, making the challenge of breadboarding your own Z80-based microcomputer that much tougher. Yet one thing that definitely won’t happen is any of us witnessing the end of the era of the Z80, 6502 and 8051 architectures.

Thanks to [Techokami] for the tip.

This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto”

Source Code To The 1999 FPS Game Descent 3 Released

On April 16th of this year, [Kevin Bentley] released the source code to the Sci-Fi FPS game Descent 3. Originally released in 1999 for Windows, the game has you control a flying ship which you have to guide through both in- and outdoor environments, while shooting at robots that have been infected with an alien virus as you try to save the solar system. It was later also ported to Mac OS and Linux, but was considered a commercial flop due to low sales.

As one of the original developers, [Kevin] explains that one of the goals of this code release is to give the game a second life, by cleaning up the C++ code and using new APIs. Original proprietary audio and video libraries from Interplay were removed, which means that some work is required before one can build a fresh copy of the game from this code base. That said, the released code is the latest 1.5 patch level, with the Mac OS and Linux support. Even if the original Descent games weren’t your cup of tea, it’s still great to see games being preserved and updated like this.

Thanks to [Phil Ashby] for the tip.

This Go-Kart Rides On A Pallet

Many beginner woodworkers, looking to offset the introductory costs of starting a hobby, will source their wood from pallets. Generally they’re easily found and can be low or no cost, but typically require a bit of work before they’re usable in a project. [Garage Avenger] is looking to do something a little outside of the box with his pallet project, though. He’s using raw pallets as a chassis for a four-speed go-kart, partially for the challenge and excitement and also to one-up a Pinterest post.

Almost immediately, though, the other major downside of working with pallets arose which is that they’re generally built out of low-grade pine which is soft and flexible. Flexibility is generally not a good thing to have in a vehicle frame so plenty of the important parts of this build were strengthened with steel tubing including the rear axle, steering mounts, and a few longitudinal supports to strengthen the overall frame. After working out some kinks with ordering a few of the wrong parts, and mounting the steering box backwards, it was time to test out the four-speed engine (and brakes) on the the go-kart, making it nearly ready for the road.

To complete the build, some tidying of wiring and fuel lines was done, along with improving some of the non-critical parts of the build like the bucket seat. Of course, adding pallet spoilers and body kit puts the finishing touches on the build and the go-kart is finally ready to tear up the local go-kart track and the less-inspiring Pinterest projects. [Garage Avenger] is no stranger to strange vehicle builds, either. Although it’s a bit out of season for most of our northern hemisphere readers now, his jet-powered street sled is still worth a view.

Continue reading “This Go-Kart Rides On A Pallet”

This Week In Security: BatBadBut, DLink, And Your TV Too

So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.

When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.

And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.

Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”

The Future Looks Bleak For Alexa Skill Development

While the average Hackaday reader is arguably less likely than most to install a megacorp’s listening device in their home, we know there’s at least some of you out there that have an Amazon hockey puck or two sitting on a shelf. The fact is, they offer some compelling possibilities for DIY automation, even if you do have to jump through a few uncomfortable hoops to bend them to your will.

That being said, we’re willing to bet very few readers have bothered installing more than a few Alexa Skills. But that’s not a judgment based on any kind of nerd stereotype — it’s just that nobody seems to care about them. A fact that’s evidenced by the recent revelation that even Amazon looks to be losing interest in the program. In a post on LinkedIn, Skill developer [Mark Tucker] shared an email he received from the mothership explaining they were ending the AWS Promotional Credits for Alexa (APCA) program on June 30th.

Continue reading “The Future Looks Bleak For Alexa Skill Development”