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” →

The WiFi Repeater You Probably Have On Your Bench

December 25, 2017 by Al Williams 29 Comments

Few things are as frustrating as a WiFi signal that drops in and out. On a public network it is bad enough but at home? Even if you can live with it, your cohabitants will certainly impune your technical abilities if they don’t have solid WiFi. One solution is a WiFi repeater. You can buy one, of course. But you can also make one out of an ESP8266 and some code from GitHub. There is also a video about the project, below.

[Martin Ger’s] code implements NAT, so it isn’t a true WiFi repeater, but more of a bridge or router. Of course, that means performance isn’t stellar, but tests show it can sustain about 5 Mbps, which isn’t bad for a little board that costs a couple of bucks. There is a limit of 8 clients, but that’s more than enough for a lot of cases. Even if you don’t want to use it as a router, it has a mesh mode that could be a basis for some interesting projects all by itself.

Continue reading “The WiFi Repeater You Probably Have On Your Bench” →

How Much Of A Battery Pack Does Your Electric Car Need?

December 25, 2017 by Jenny List 143 Comments

[Elon Musk] recently staged one of his characteristic high-profile product launches, at which he unveiled a new Tesla electric semi-truck. It was long on promise and short on battery pack weight figures, so of course [Real Engineering] smelled a rat. His video investigating the issue is below the break, but it’s not the link that caught our eye for this article. As part of the investigation he also created an online calculator to estimate the battery size required for a given performance on any electric vehicle.

It’s not perfectly intuitive, for example it uses SI units rather than real-world ones so for comparison with usual automotive figures a little mental conversion is needed from kilometres and hours to metres and seconds if you’re a metric user, and miles if you use Imperial-derived units. But still it’s a fascinating tool to play with if you have an interest in designing electric cars or conversions, as you can tweak the figures for your chosen vehicle indefinitely to find the bad news for your battery pack cost.

It’s very interesting from a technical standpoint to see a credible attempt at an electric truck, and we hope that the existing truck manufacturers will show us more realistic prototypes of their own. But we can’t help thinking that the overall efficiency of electric long-distance trucking could be improved hugely were they to make a truck capable of hauling more than one trailer at once. Any safety issues could be offset by giving these super-trucks their own highways, and with such dedicated infrastructure the power could be supplied from roadside cables rather than heavy batteries. In such circumstances these long trains of electrically hauled containers could be rather successful, perhaps we might call them railroads.

Continue reading “How Much Of A Battery Pack Does Your Electric Car Need?” →