Old mainframe computers are interesting, especially to those of us who weren’t around to see them in action. We sit with old-timers and listen to their stories of the good ol’ days. They tell us about loading paper tape or giving instructions one at a time with toggle switches and LED output indicators. We hang on every word because its interesting to know how we got to this point in the tech-timeline and we appreciate the patience and insanity it must have taken to soldier on through the “good ol’ days”.
Ken describes in thorough detail how the IBM 1401 — which was first introduced in 1959 — takes a decimal number as an input and operates on it one BCD digit at a time. Before performing the instruction the BCD number is converted to qui-binary. Qui-binary is represented by 7 bits, 5 qui bits and 2 binary bits: 0000000. The qui portion represents the largest even number contained in the BCD value and the binary portion represents a 1 if the BCD value is odd or a 0 for even. For example if the BCD number is 9 then the Q8 bit and the B1 bit are set resulting in: 1000010.
The qui-binary representation makes for easy error checking since only one qui bit should be set and only one binary bit should be set. [Ken] goes on to explain more complex arithmetic and circuitry within the IBM 1401 in his post.
By the turn of the 19th century, most scientists were convinced that the natural world was composed of atoms. [Einstein’s] 1905 paper on Brownian motion, which links the behavior of tiny particles suspended in a liquid to the movement of atoms put the nail in the coffin of the anti-atom crowd. No one could actually see atoms, however. The typical size of a single atom ranges from 30 to 300 picometers. With the wavelength of visible light coming in at a whopping 400 – 700 nanometers, it is simply not possible to “see” an atom. Not possible with visible light, that is. It was the summer of 1982 when Gerd Binnig and Heinrich Rohrer, two researchers at IBM’s Zurich Research Laboratory, show to the world the first ever visual image of an atomic structure. They would be awarded the Nobel prize in physics for their invention in 1986.
The Scanning Tunneling Microscope
IBM’s Scanning Tunneling Microscope, or STM for short, uses an atomically sharp needle that passes over the surface of an (electrically conductive) object – the distance between the tip and object being just a few hundred picometers, or the diameter of a large atom.
A small voltage is applied between the needle and the object. Electrons ‘move’ from the object to the needle tip. The needle scans the object, much like a CRT screen is scanned. A current from the object to the needed is measured. The tip of the needle is moved up and down so that this current value does not change, thus allowing the needle to perfectly contour the object as it scans. If one makes a visual image of the current values after the scan is complete, individual atoms become recognizable. Some of this might sound familiar, as we’ve seen a handful of people make electron microscopes from scratch. What we’re going to focus on in this article is how these electrons ‘move’ from the object to the needle. Unless you’re well versed in quantum mechanics, the answer might just leave your jaw in the same position as this image will from a home built STM machine.
In days of yore, one could mine Bitcoin without much more than an AMD graphics card. Now, without specialized hardware it’s unlikely that you’ll make any appreciable headway in the bitcoin world. This latest project, however, goes completely in the other direction: [Ken] programmed a 55-year-old IBM mainframe to mine Bitcoin. Note that this is technically the most powerful rig ever made… if you consider the power usage per hash.
Engineering wordplay aside, the project is really quite fascinating. [Ken] goes into great detail about how Bitcoin mining actually works, how to program an assembly program for an IBM 1401 via punch cards, and even a section about networking a computer from this era. (Bonus points if he can get retro.hackaday.com to load!) The IBM boasts some impressive stats for the era as well: It can store up to 16,000 characters in memory and uses binary-coded decimal. All great things if you are running financial software in the early ’60s or demonstrating Bitcoin in the mid-2010s!
If it wasn’t immediately obvious, this rig will probably never mine a block. At 80 seconds per hash, it would take longer than the lifetime of the universe to do, but it is quite a feat of computer science to demonstrate that it is technically possible. This isn’t the first time we’ve seen one of [Ken]’s mainframe projects, and hopefully there are more gems to come!
The demoscene usually revolves around the Commodore 64, and when you compare the C64 hardware to other computers of a similar vintage, it’s easy to see why. There’s a complete three-voice synthesizer on a chip, the hardware allows for sprites, a ton of video pages, and there are an astounding sixteen colors, most of which look good. You’re not going to find many demos for the Apple II, because the graphics and sound are terrible. You’re also not going to find many demos for an original IBM PC from 1981, because for thirty years, the graphics and audio have been terrible.
8088 MPH by [Hornet], [CRTC], and [DESire], the winner of the recent 2015 Revision Demo compo just turned conventional wisdom on its head. It ran on a 4.77 MHz 8088 CPU – the same found in the original IBM PC. Graphics were provided via composite output by a particular IBM CGA card, and sound was a PC speaker beeper, beeping sixty times a second. Here’s a capture of the video.
Because of the extreme nature of this demo, it is unable to run on any emulator. While the initial development happened on modern machines with DOSbox, finishing the demo needed to happen on an IBM 5160, equivalent to the 5150, but much easier to find.
Despite the meager hardware and a CPU that reads a single byte in four cycles, effectively making this a 1.19 MHz CPU, the team produced all the usual demoscene visuals. There are moire patterns, bobbing text, rotated and scaled bitmaps, and an astonishing 1024-color mode that’s an amazing abuse of 80×25 text mode with NTSC colorburst turned on.
Below you can find a video of the demo, and another video of the audience reaction at the Revision compo.
SAGE was developed at MIT’s Lincoln Laboratory on computers built by IBM. It used the AN/FSQ-7 in fact, which was The Largest Computer Ever Built. SAGE operated as a network of defense sectors that divided the continental U.S. and Canada. Each of these sectors contained a directional center, which was a four-story concrete blockhouse that protected and operated a ‘Q7 through its own dedicated power station. The SAGE computers employed hot standby processors for maximum uptime and would fail over to nearby direction centers when necessary.
Information is fed into each directional center from many radar sources on land, in the air, and at sea. The findings are evaluated on scopes in dimly-lit rooms on the front end and stored on magnetic cores on the back end. Unidentifiable aircraft traces processed in the air surveillance room of the directional center are sent to the ID room where they are judged for friendliness. If found unfriendly, they are sent to the weapons direction room for possible consequences.
The IBM 1401 is an odd beast. Even though it’s a fully transistorized computer, these transistors are germanium. These transistors are stuffed onto tiny cards with resistors, caps, and diodes, than then stuck in a pull-out card cage that, in IBM parlance, is called a ‘gate’. The computer used decimal arithmetic, and things like ‘bytes’ wouldn’t be standard for 20 years after this computer was designed – 4,000 characters of memory are stored in a 6-bit binary coded decimal format.
To the modern eye, the 1401 appears to be a very odd machine, but thanks to the ROPE compiler, [Ken] was able to develop his code and run it before committing it to punched cards. An IBM 029 keypunch was used to send the code from a PC to cards with the help of some USB-controlled relays.
With the deck of cards properly sorted, the 1401 was powered up, the cards loaded, and the impressive ‘Load’ button pressed. After 12 minutes of a line printer hammering out characters one at a time, a Mandelbrot fractal appears from a line printer. Interestingly, the first image of the Mandelbrot set was printed off a line printer in 1978. The IBM 1401 was introduced nearly 20 years before that.
We’ve all seen the social logon pop up boxes. You try to log into some website only to be presented with that pop up box that says, “Log in with Facebook/Twitter/Google”. It’s a nice idea in theory. You can log into many websites by using just one credential. It sounds convenient, but IBM X-Force researchers have recently shown how this can be bad for the security of your accounts. And what’s worse is you are more vulnerable if the service is offered and you are NOT using it. The researcher’s have called their new exploit SpoofedMe. It’s aptly named, considering it allows an attacker to spoof a user of a vulnerable website and log in under that user’s account.
So how does it work? The exploit relies on vulnerabilities in both the identity provider (Facebook/Twitter/etc) and the “relying website”. The relying website is whatever website the user is trying to log into using their social media account. The easiest way to describe the vulnerability is to walk through an example. Here we go.
Let’s imagine you are an attacker and you want to get into some victim’s Slashdot account. Slashdot allows you to create a local account within their system if you like, or you can log in using your LinkedIn account. Your victim doesn’t actually have a LinkedIn account, they use a local Slashdot account.
The first step of your attack would be to create a LinkedIn account using your victim’s email address. This needs to be the same address the victim is using for their local Slashdot account. This is where the first vulnerability comes in. LinkedIn needs to allow the creation of the account without verifying that the email address belongs to you.
The second step of the attack is now to attempt to log into Slashdot using your newly created LinkedIn account. This is where the second vulnerability comes in. Some social media services will authenticate you to websites like Slashdot by sending Slashdot your user information. In this case, the key piece of information is your email address. Here’s the third vulnerability. Slashdot sees that your LinkedIn account has the same email address as one of their local users. Slashdot assumes that LinkedIn has verified the account and permits you, the attacker, to log in as that user. You now have access to your victim’s Slashdot account. In another scenario, Slashdot might actually merge the two credentials together into one account.
What’s really interesting about this hack is that it isn’t even very technical. Anyone can do this. All you need is the victim’s email address and you can try this on various social media sites to see if it works. It’s even more interesting that you are actually more vulnerable if you are not using the social logons. Some real world examples of this vulnerability are with LinkedIn’s social logon service, Amazon’s service, and MYDIGIPASS.com’s service. Check out the demonstration video below. Continue reading “SpoofedMe Attack Steals Accounts by Exploiting Social Login Mechanisms”→