Laptop With Raspberry Pi Inside Learns To Speak Battery

December 30, 2017 by Mike Szczys 6 Comments

Early in November we took a look at a one of the best Raspberry Pi laptops we had ever seen, using the shell of a Sony VAIO. Laptops used to be hulking beasts, and that played into [Frank Adams’] hands as he got rid of the motherboard and had enough space to replace it with a Raspberry Pi and a few other support boards. This took advantage of the laptop’s screen, keyboard, LEDs, etc. But what’s a laptop without battery power? [Frank] hadn’t cracked that nut until now.

Inside of Sony VAIO laptop turned Raspberry Pi computer — VAIO battery and charging PCB seen to lower left

Adding battery power is trickier that it sounds, but [Frank] managed to get the Raspberry Pi to talk to the original Sony VAIO internal battery. His work on the project is shared, but this part of the story is best found starting on page 29 of his PDF project details.

Using the original battery is a good move since it’s designed to fit and has a charger ready to interface with the port on the laptop case. But these batteries have logic inside them, and there’s the rub. Communications use the 2-wire System Management Bus (SMBus) which is well documented. But the when trying to use the Pi’s I2C [Frank] couldn’t figure out to send a repeated start command.

He ended up writing his own C program that bit-bangs the communications he needed and now has the Pi speaking to the battery and listening to what it hears coming back. Reading through his description of this is fun since he includes his observations from a logic analyzer captures. He suspects an occasional bad read is due to Linux interrupting code execution. He watches for and catches these bad reads in software and can now reliably read all the battery vitals.

The hack leaves him with a system that functions in much the same way the original computer did: plug it in and it charges. He did add some hardware that lets him take a voltage reading from the battery using an ADC on the Teensy that was already present to control the keyboard and case LEDs. This adds a small constant draw on the battery, but for now he doesn’t leave the battery connected when the laptop is not in use.

If you’d like to read our original coverage of this laptop, here it is.

34C3: Hacking The Nintendo Switch

December 29, 2017 by Tom Nardi 37 Comments

There’s a natural order to the world of game console hacking: every time a manufacturer releases a new game console they work in security measures that prevent the end user from running anything but commercially released games, and in turn every hacker worth his or her salt tries to break through. The end goal, despite what the manufacturers may have you believe, is not to run “bootleg” games, but rather to enable what is colloquially referred to as “homebrew”. That is to say, enabling the novel concept of actually running software of your choice on the hardware you paid for.

At 34C3, noted console hackers [Plutoo], [Derrek], and [Naehrwert] have demonstrated unsigned code running on Nintendo’s latest and greatest and while they are keeping the actual exploit to themselves for now, they’ve promised that a platform for launching homebrew is coming shortly for those who are on firmware version 3.0.0. From the sound of it, after 9 months on the market, Switch owners will finally have complete access to the hardware they purchased.

The key to running the team’s own code was through a WebKit exploit that was already months old by the time the Switch was released. Loading up an arbitrary webpage was the tricky part, as the Switch generally uses its web browser for accessing official sources (like the online game store). But hidden away in the help menus of Tetris, the developers helpfully put a link to their website which the Switch will dutifully open if you select it. From there it’s just a matter of network redirection to get the Switch loading a webpage from your computer rather than the Internet.

It’s easier to ask for forgiveness than permission.

But as the more security-minded of our readers may have guessed already, that just gets you into the browser’s sandbox. The team now had to figure out a way to break out and get full control of the hardware. Through a series of clever hacks the team was able to learn more about the Switch’s internal layout and operating system, slowly working their way up the ladder.

A particularly interesting hack was used to get around a part of the Switch’s OS that is designed to check which services code is allowed to access. It turns out that if code doesn’t provide this function with its own process ID (PID), the system defaults to PID 0 because the variable is not initialized. In other words, if you don’t ask the operating system which functions you have access to, you will get access to them all. This is a classic programming mistake, and a developer at Nintendo HQ is likely getting a very stern talking to right about now.

But not everything was so easy. When trying to get access to the boot loader, the team sniffed the eMMC bus and timed the commands to determine when it was checking the encryption keys. They were then able to assemble a “glitcher” which fiddled with the CPU’s power using FPGA controlled MOFSETs during this critical time in an attempt to confuse the system.

The rabbit hole is pretty deep on this one, so we’d recommend you set aside an hour to watch the entire presentation to see the long road it took to go from a browser bug to running their first complete demo. It’s as much a testament to the skill of [Plutoo], [Derrek], and [Naehrwert] as it is the lengths at which Nintendo went to keep people out.

We’ve seen other attempts at reverse engineering Nintendo’s hardware, but by the looks of it, the Switch has put up a much harder fight than previous console generations. Makes you wonder what tricks Nintendo will have up their sleeves for the next generation.

Continue reading “34C3: Hacking The Nintendo Switch” →

Try This For 3D Printing Without Support

December 29, 2017 by Al Williams 46 Comments

Have a look at the object to the right. Using a conventional fused deposition printer, how would you print the object? There’s no flat surface to lay on the bed without generating a lot of overhangs. That usually requires support.

In theory, you might be able to print the bottom of the sphere down, but it is difficult to get that little spot to adhere to the bed. If you have at least two extruders and you are set up to print support material, that might even be the best option. However, printing support out of the same material you are printing with makes it hard to get a good clean print. There is another possibility. It does require some post-processing, but then again, not as much as hacking away a bunch of support material.

A Simple Idea

The idea is simple and — at first — it will sound like a lot of trouble. The basic idea is to cut the model in half at some point where both halves would be easy to print and then glue them together. Stick around (no pun intended), though, because I’ll show you a way to make the alignment of the parts almost painless no matter how complex the object might be.

The practical problem with gluing together half models is getting the pieces in the exact position, but that turns out to be easy if you just make a few simple changes to your model. Another lesser problem is clamping a piece while gluing. You can use a vise, but some oddly-shaped parts are not conducive to traditional vise jaws.

In Practice

Starting with an OpenSCAD object, it is easy to cut the model in half. Actually, you could cut it anywhere. Then it is easy to rotate half of it so the cut line is at the bottom of each part. That doesn’t solve the alignment problem nor does it help you clamp when you glue.

The trick is to build a flange around each part. The flanges mate with a few screws after printing so alignment is perfect and bolts through the flange holes can keep the parts together and immobilized while your glue of choice sets. The kicker is that I even have an automated process to make the design side of this trick very easy.

Continue reading “Try This For 3D Printing Without Support” →

34C3: Hacking Into A CPU’s Microcode

December 28, 2017 by Elliot Williams 67 Comments

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

2017: As The Hardware World Turns

December 27, 2017 by Brian Benchoff 28 Comments

The year is almost over, and now it’s time to look back on the last fifty-odd weeks. What happened in this year in hacking? 2017 will go down as the beginning of another AI renaissance, although we’re not going to call it that; this year was all about neural nets and machine learning and advancements resulting from the development of self-driving cars and very beefy GPUs. Not since the 80s have we seen more work in ‘AI’ fields. What will it amount to this time around the hype cycle? Find out in a few years.

Biohacking was big this year, and not just because people are installing RFID tags and magnets in their hands. CRISPR is allowing for Star Trek-style genome hacking, and this year saw in vivo experiments to enable and disable individual genes in rat models. Eventually, someone is going to get a Nobel for CRISPR.

We’re going to Mars, and soon — very soon — a SpaceX Falcon Heavy is going to either lob a Tesla Roadster into solar orbit or the Atlantic Ocean. We learned about the BFR that will take dozens of people to Mars in a single launch. Boeing and Lockheed think they can compete with the Elon Musk PR powerhouse. The Bigelow Aerospace inflatable module passed its in-flight test on the ISS, giving the space station a new storage closet. Even in space, amazing stuff is happening this year.

Is that it? Not by a long shot. This year has seen some of the coolest hacks we’ve ever seen, and some of the dumbest security breaches ever. Hackaday is doing awesome. What else did 2017 have? Read on to find out.

Continue reading “2017: As The Hardware World Turns” →

A Visit From Saint Rich

December 26, 2017 by Dan Maloney 12 Comments

With apologies to Clement Clarke Moore, Richard Stallman, and the English-speaking world in general — ed.

‘Twas the night before Christmas
While up in my bed,
I stared at the ceiling
With feelings of dread.

I’d really no reason for portents of doom
Lying there, sleepless, in gathering gloom.
We’d wrapped all the presents, and decked out the tree,
But still, there was something niggling at me.

Continue reading “A Visit From Saint Rich” →

Fast 3D Printing With Raspberry Pi — But Not How You Think

December 26, 2017 by Al Williams 117 Comments

Although we tend to think of 3D printers as high-tech toys, most of them are not especially powerful in the brain department. There are some exceptions, but most 3D printers run on either an 8-bit Arduino or some Arduino variant with a lot of I/O. There are a few 32-bit boards, but if you grab a random 3D printer, its brain is going to be an 8-bit AVR running something like Marlin or Repetier. It isn’t uncommon to see a Raspberry Pi connected to a printer, too, but — again, in general — it is a network interface that handles sending G-code to the 8-bit controller that runs the stepper motors. Would it make more sense to do things like parse G-code, map out curves, and set accelerations in the relatively powerful Raspberry Pi and relegate the 8-bit AVR to just commanding motors and heaters? [KevinOConnor] thinks so, and he wrote Klipper to prove it.

Klipper is mostly written in Python and it does most of the functions of traditional 3D printing firmware. It communicates with the onboard microprocessor by providing a schedule of when to do what tasks. The microprocessor then handles the timing and things like motion control for the axes and extruder. Klipper can control multiple microprocessors with no trouble and keeps them in synchronization, so you could have a processor for your extruder and one for each stepper, for example. You can use Klipper with a Cartesian machine, a delta, or a Core XY-style printer.

Continue reading “Fast 3D Printing With Raspberry Pi — But Not How You Think” →