It’s a story that may be familiar to many of us, that of bidding on an item in an online auction and discovering once we go to pick it up that we’ve bought a bit more than we’d bargained for. We told you earlier in the year about the trio of Brits who bought an IBM System/360 mainframe computer from the mid 1960s off of a seller in Germany, only to find in the long-abandoned machine room that they’d bought not just one but two 360s, and a System/370 to boot. Their van was nowhere near big enough for all three machines plus a mountain of cabling, documentation, and period storage media, so they moved it to a hastily-rented storage unit and returned home to work out what on earth to do next.
Now we’ve received an email from the trio with some good news; not only have they managed to bring their hoard of vintage big iron computing back home, but also they’ve found a home for it in the rather unusual surroundings of a former top-secret UK Government signals intelligence station. With the help of a friendly specialist IT relocation company they unleashed it from their temporary storage and into the truck for the UK. It’s a tale of careful packing and plenty of wrapped pallets, as we begin to glimpse the true extent of the collection as you can see in the video below the break, because not only have they secured all the hardware but they also have a huge quantity of punched cards and disk packs. The prospect of a software archaeology peek into how a 1960s mainframe was used by its original customer is a particularly interesting one, as it’s likely those media contain an ossified snapshot of its inner workings.
We’re hoping to follow this project as it evolves, and see (we hope) a room full of abandoned junk transformed into a facsimile of a typical 1960s business computing setup. If you’d like to catch up, read our original coverage of the find.
Most of us will be familiar at some level with the operation of a basic CPU, usually through exposure to microprocessors of the type that find their way into our projects. We can look at its internal block diagram and get how it works, see the registers and ALU, follow the principles of a von Neumann architecture, and understand that it has an instruction set with different instructions for each of its functions. We all know that this only describes one type of CPU though, and thus it’s always interesting to see alternatives. [Ike Jr] then has a project that should provide a lot of interest, it’s a CPU that only has a single instruction. It can only move data from one place to another, which seems to preclude any possibility of computation. How on earth can it work?
The machine has a set of registers as well as memory, and it achieves computation by having specific registers where we might expect to see instructions. For example the AND register is a two-position stack, that when it is full computes the AND of its two pieces of data and places the result in a general purpose register. The write-up goes into significant detail on the CPU’s operation, and while it’s unlikely the world will move en masse to this architecture it’s still a very interesting read. For now this is a machine that exists in software simulation rather than in silicon, and he’s working to release it so enthusiasts for unusual CPUs can have a go.
CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.
On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg”→
Microsoft seems to have an every-other-version curse. We’re not sure how much of this is confirmation bias, but consider the track record of releases. Windows 95 was game-changing, Windows 98 famously crashed during live demo. Windows 2000 was amazing, Windows ME has been nicknamed the “Mistake Edition”. XP was the workhorse of the world for years and years, and Vista was… well, it was Vista. Windows 7 is the current reigning champion of desktop installs, and Windows 8 was the version that put a touchscreen interface on desktops. The “curse” is probably an example of finding patterns just because we’re looking for them, but the stats do show a large crowd clinging to Windows 7.
Windows 10 made a name for itself by automatically installing itself on Windows 7 and Windows 8 computers, much to the annoyance of many unexpecting “victims” of that free upgrade. Several years have gone by, Windows 10 has gotten better, and support for Windows 7 ends in January. If you’re tied to the Windows ecosystem, it’s time to upgrade to Windows 10. It’s too bad you missed out on the free upgrade to Windows 10, right?
About that… It’s probably an unintended side effect, but all valid Windows 7 and Windows 8 keys are also valid Windows 10 keys. Activation is potentially another issue, but we’ll get to that later.
Back in the early days of computing, user terminals utilized line printers for output. Naturally this took an incredible amount of paper, but it came with the advantage of creating a hard copy of everything you did. Plus it was easy to annotate the terminal output with nothing more exotic than a ballpoint pen. But once CRT displays became more common, these paper terminals (also known as teleprinters, or teletypes) quickly fell out of style.
A fan of nostalgic hacks, [Drew DeVault] recently tried to recreate the old-school teletype experience with (somewhat) more modern hardware. He picked up an Epson LX-350 line printer, and with a relatively small amount of custom code, he was able to create a fairly close approximation of what it would have been like to use one of these terminals. He’s published all the source code, so if you’ve got an old line printer and a Linux box, you too can learn what it was like to measure your work day in reams of paper.
This is made possible by the fact that the modern Linux virtual terminal is simply a userspace emulation of those physical terminals of yore. [Drew] just need to write some code that would essentially spawn a shell on the Linux USB line printer device, plus sprinkle in some quality of life improvements such as using Epson’s proprietary ANSI escape sequences to feed the paper out far enough so the user can see what it says before pulling it back in to write the next interactive line.
The modern laptop has its origins in the mid to late 1980s, when shrinking computer hardware and improvements to battery technology finally made mobile computing practical. But before the now iconic clamshell form factor became the standard, there was a market for so-called “portable” computers. These machines often resembled pieces of luggage with keyboards attached, and even at their peak, they were nowhere near as practical as today’s ultra-thin notebook computers. But for the more nostalgic among us, these vintage portables do have a special sort of charm about them.
Looking to recapture some of that magic with modern components, [davedarko] has started working on his own Raspberry Pi portable computer. Just like those machines of yore, his build is designed to be a self-contained computing experience that you can lug around, but not exactly something you’d be popping open on the train. Its extruded aluminum frame holds the display, power supply, and audio hardware, with plenty of room to spare for additional hardware should he decide to pack in a couple hard drives or something more exotic.
We particularly like the 3D printed hinge and lock mechanism he designed that holds the keyboard closed against the front of the frame. Sufficiently old experienced readers will recall this particular feature being a defining characteristic of portables such as the Osborne 1 and Compaq Portable, and it’s great to see it included here. All it needs now is a leather handle on the side to complete the look.
[davedarko] still has some work ahead of him, as ultimately he’d like to completely enclose his computer’s frame with laser cut panels. But the build is certainly progressing nicely, and frankly, it’s already at the point where we’d have no problem pulling it out at the next hackerspace meetup. Between builds like this and the growing collection of cyberdecks we’ve covered recently, it looks as though 1980s design aesthetic is alive and well within the hacker community.
When fiddling around with old computers, you can occasionally find yourself in a sticky situation. What may be a simple task with today’s hardware and software can be nearly impossible given the limited resources available to machines with 20 or 30 years on the clock. That’s where [bison] recently found himself when he needed to configure a device over serial, but didn’t have any way of installing the appropriate terminal emulator on his Fujitsu Lifebook C34S.
His solution, since he had Python 2.6 installed on the Debian 6 machine, was to write his own minimal serial terminal emulator. He intended for the code to be as terse as possible so it could be quickly typed in, should anyone else ever find themselves in need of talking to a serial device on Linux but can’t get screen or minicom installed.
The code is very simple, and even if you never find yourself needing to fire up an impromptu terminal, it offers an interesting example of how straightforward serial communications really are. The code opens up the /dev/ttyS0 device for reading, and after appending the appropriate return character, pushes the user’s keyboard input into it. Keep looping around, and you’ve got yourself an interactive terminal.