Ditch The IPad; Build A Commodore 64 Tablet

November 16, 2015 by Kevin Dady 17 Comments

The classic Commodore 64 has had its share of modernizing in the OS department. From its roots starting up a basic prompt, to full high resolution GUI packages like GEOS, to today where [Jim_64] added a tablet like launcher complete with a touch screen interface.

The GUI itself takes advantage of the high resolution graphics of the C-64 that looks similar to iOS, Icons are selected via cursor keys or joystick (what? no light pen?) and launch the various functions they represent. To add to the tablet-like feel of the OS, an off the shelf 3m touch screen panel and its corresponding RS232 interface board were obtained from digikey.

With the panel securely attached to the monitor, XY data from the various finger pokes are sent via serial at a blazing 1200 bps where the program interprets the position. Using the available demo (download sideA and sideB) and off the shelf parts, this should be easy for anyone with a classic C-64 to set up in their own home and have some fun.

Join us after the break for a few demo videos!

Continue reading “Ditch The IPad; Build A Commodore 64 Tablet” →

Physical Security For Desktop Computers

November 13, 2015 by Brian Benchoff 134 Comments

There’s a truism in the security circles that says physical security is security. It doesn’t matter how many bits you’ve encrypted your password with, which elliptic curve you’ve used in your algorithm, or if you use a fingerprint, retina scan, or face print for a second factor of authentication. If someone has physical access to a device, all these protections are just road bumps in the way of getting your data. Physical access to a machine means all that data is out in the open, and until now there’s nothing you could do to stop it.

This week at Black Hat Europe, Design-Shift introduced ORWL, a computer that provides the physical security to all the data sitting on your computer.

The first line of protection for the data stuffed into the ORWL is unique key fob radio. This electronic key fob is simply a means of authentication for the ORWL – without it, ORWL simply stays in its sleep mode. If the user walks away from the computer, the USB ports are shut down, and the HDMI output is disabled. While this isn’t a revolutionary feature – something like this can be installed on any computer – that’s not the biggest trick ORWL has up its sleeve.

The big draw to the ORWL is a ‘honeycomb mesh’ that completely covers every square inch of circuit board. This honeycomb mesh is simply a bit of plastic that screws on to the ORWL PCB and connects dozens of electronic traces embedded in this board to a secure microcontroller. If these traces are broken – either through taking the honeycomb shell off or by breaking it wide open, the digital keys that unlock the computer are erased.

The ORWL specs are what you would expect from a bare-bones desktop computer: Intel Skylake mobile processors, Intel graphics, a choice of 4 or 8GB of RAM, 64 to 512GB SSD. WiFi, two USB C ports, and an HDMI port provide all the connections to the outside world.

While this isn’t a computer for everyone, and it may not even a very large deployment, it is an interesting challenge. Physical security rules over all, and it would be very interesting to see what sort of attack can be performed on the ORWL to extract all the data hidden away behind an electronic mesh. Short of breaking the digital key hidden on a key fob, the best attack might just be desoldering the chips for the SSD and transplanting them into a platform more amenable to reading them.

In any event, ORWL is an interesting device if only for being one of the few desktop computers to tackle the problem of physical security. As with any computer, if you have physical access to a device, you have access to all the data on the device; we just don’t know how to get the data off one of these tiny computers.

Video below.

Continue reading “Physical Security For Desktop Computers” →

Stegosploit: Owned By A JPG

November 6, 2015 by Elliot Williams 34 Comments

We’re primarily hardware hackers, but every once in a while we see a software hack that really tickles our fancy. One such hack is Stegosploit, by [Saumil Shah]. Stegosploit isn’t really an exploit, so much as it’s a means of delivering exploits to browsers by hiding them in pictures. Why? Because nobody expects a picture to contain executable code.

[Saumil] starts off by packing the real exploit code into an image. He demonstrates that you can do this directly, by encoding characters of the code in the color values of the pixels. But that would look strange, so instead the code is delivered steganographically by spreading the bits of the characters that represent the code among the least-significant bits in either a JPG or PNG image.

OK, so the exploit code is hidden in the picture. Reading it out is actually simple: the HTML canvas element has a built-in getImageData() method that reads the (numeric) value of a given pixel. A little bit of JavaScript later, and you’ve reconstructed your code from the image. This is sneaky because there’s exploit code that’s now runnable in your browser, but your anti-virus software won’t see it because it wasn’t ever written out — it was in the image and reconstructed on the fly by innocuous-looking “normal” JavaScript.

And here’s the coup de grâce. By packing HTML and JavaScript into the header data of the image file, you can end up with a valid image (JPG or PNG) file that will nonetheless be interpreted as HTML by a browser. The simplest way to do this is send your file myPic.JPG from the webserver with a Content-Type: text/html HTTP header. Even though it’s a totally valid image file, with an image file extension, a browser will treat it as HTML, render the page and run the script it finds within.

The end result of this is a single image that the browser thinks is HTML with JavaScript inside it, which displays the image in question and at the same time unpacks the exploit code that’s hidden in the shadows of the image and runs that as well. You’re owned by a single image file! And everything looks normal.

We like this because it combines two sweet tricks in one hack: steganography to deliver the exploit code, and “polyglot” files that can be read two ways, depending on which application is doing the reading. A quick tag-search of Hackaday will dig up a lot on steganography here, but polyglot files are a relatively new hack.

[Ange Ablertini] is the undisputed master of packing one file type inside another, so if you want to get into the nitty-gritty of [Ange]’s style of “polyglot” file types, watch his talk on “Funky File Formats” (YouTube). You’ll never look at a ZIP file the same again.

Sweet hack, right? Who says the hardware guys get to have all the fun?

Winning The Console Wars – An In-Depth Architectural Study

November 6, 2015 by Brian Benchoff 79 Comments

From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.

The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.

In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.

Continue reading “Winning The Console Wars – An In-Depth Architectural Study” →

Slide Rules Were The Original Personal Computers

November 5, 2015 by Al Williams 67 Comments

Unless you are above a certain age, the only time you may have seen a slide rule (or a slip stick, as we sometimes called them) is in the movies. You might have missed it, but slide rules show up in Titanic, This Island Earth, and Apollo 13. If you are a fan of the original Star Trek, Mr. Spock was seen using Jeppesen CSG-1 and B-1 slide rules in several episodes. But there was a time that it was common to see an engineer with a stick hanging from his belt, instead of a calculator or a cell phone. A Pickett brand slide rule flew to the moon with the astronauts and a K&E made the atomic bomb possible.

Slide rules are a neat piece of math and history. They aren’t prone to destruction by EMP in the upcoming apocalypse (which may or may not include zombies). Like a lot of things in life, when it comes to slide rules bigger is definitely better, but before I tell you about the 5 foot slide rule in my collection, let’s talk about slide rules in general.
Continue reading “Slide Rules Were The Original Personal Computers” →

The IBM 1401’s Unique Qui-Binary Arithmetic

November 5, 2015 by Brandon Dunson 12 Comments

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 Shirriff] is making those good ol’ days come alive with a series of articles relating to his work with hardware at the Computer History Museum. His latest installment is an article describing the strange implementation of the IBM 1401’s qui-binary arithmetic. Full disclosure: It has not been confirmed that [Ken] is an “old-timer” however his article doesn’t help the argument that he isn’t.

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.

If you aren’t familiar with [Ken], we covered his reverse engineering of the Sinclair Scientific Calculator, his explanation of the TL431, and of course the core memory repair that is part of his Computer History Museum work.

Thanks for the tip [bobomb].

One Dollar USB Sound Card Turned O-Scope

November 4, 2015 by Kevin Dady 40 Comments

Using the inputs on a computer’s sound card is an old trick to fake a very simplistic, AC coupled, slow oscilloscope. You can get DC operation by desoldering a couple capacitors, but if the sound card is integrated into the motherboard it raises the stakes if you mess that up.

[TMSZ] has a better option, a ~1 dollar USB sound card which is easily hacked to work as a simple oscilloscope. Easily found on eBay, the 7.1 virtual channel sound card is identical in brains to a more expensive c-media model, but the layout of the PCB makes it easier to bypass the DC blocking caps. Software and DLL files to use the sound card with Miniscope v4 — a Windows GUI for oscilloscopes — are also linked, so getting set up should be fairly simple.

Now of course this is not lab-grade measurement equipment: the sampling rate is limited to 44KHz and the voltages must be in the typical “line level” range, under two volts. If you don’t mind a little extra noise, you can increase the input impedance with a single resistor. This extends the input range up to six volts, which covers most hobby and microcontroller usage.

So if you’re really in need of a scope, but only have a buck to spend, this may be just the hack for you! Those willing to shell out a hefty sum for a high-end headless oscilloscope should look onto the virtual bench.