OpenSCAD: Tieing It Together With Hull()

What’s your favorite OpenSCAD command? Perhaps it’s intersection() or difference()? Or are you a polygon() and extrude() modeler? For me, the most useful, and maybe most often overlooked, function is hull(). Hull() does just what it says on the can — creates a convex hull around the objects that are passed to it as children — but that turns out to be invaluable.

Hull() solves a number of newbie problems: making things round and connecting things together. And with a little ingenuity, hull() can provide a nearly complete modelling strategy all on its own. If you use OpenSCAD and your creations end up with hard edges, or you spend too much time figuring out angles, or if you just want to experience another way to get the job done, read on!

Continue reading “OpenSCAD: Tieing It Together With Hull()”

You Can Learn a Lot From a Blinkenrocket

At this year’s Chaos Communication Congress, we caught up with [muzy] and [overflo], who were there with a badge and soldering project they designed to teach young folks how to solder and program. Blinkenrocket is a basically a 64-LED matrix display and just enough support hardware to store and display animations, and judging by the number of blinking rockets we saw around the necks of attendees, it was a success.

Their talk at 34C3 mostly concerns the production details, design refinements, and the pitfalls of producing thousands of a thing. If you’re thinking of building a hardware kit or badge on this scale, you should really check it out and crib some of their production optimization tricks.

For instance, instead of labelling the parts “C2” or “R: 220 Ohms”, they used a simple color-coding scheme. This not only makes it easier for kids to assemble, but it also means that they didn’t have to stick 1,000 part labels on every component. Coupled with [overflo]’s Zerhacker, SMD parts in strips were cut to the right length and color-coded in one step, done by machine.

The coolest feature of the Blinkenrocket itself is the audio programming interface. It’s like in the bad old days of software stored on cassette tapes, but it’s a phenomenal interface for getting a simple animation out of a web app and straight into a piece of minimal hardware — just plug it into a laptop or cell phone’s audio out and press “play” in the browser. The original design tried to encode the data in the pulse-length of square waves, but this turned out to be very hardware dependent. The final design used frequency-shift keying. What’s old is new again.

Everything you could want to know about the design, its code, and even the website itself are up on the project’s GitHub page, so go check it out. If you’d like to arrange a Blinkenrocket workshop yourself, shoot [muzy] or [overflo] an e-mail. Full disclosure: [overflo] gave us a kit, the “hard-mode” SMD one with 0805 1206 parts, and it was fun to assemble and program.

Amazing Mechanical Linkages and The Software to Design Them

Most of us are more bits-and-bytes than nuts-and-bolts, but we have the deepest appreciation for the combination of the two. So, apparently, does [rectorsquid]. Check out the design and flow of his rolling ball sculpture (YouTube, embedded below) to see what we mean. See how the arms hesitate just a bit as the ball is transferred? See how the upper arm gently places it on the ramp with a slight downward gesture? See how it’s done with one motor? There’s no way [rectorsquid] designed this on paper, right?

Of course he didn’t (YouTube). Instead, he wrote a simulator that lets him try out various custom linkages in real time. It’s a Windows-only application (sigh), but it’s free to use, while the video guides (more YouTube) look very comprehensive and give you a quick tour of the tool. Of special note is that [rectorsquid]’s software allows for sliding linkages, which he makes very good use of in the rolling ball sculpture shown here.

We’ve actually secretly featured [rectorsquid]’s Linkage software before, in this writeup of some amazing cosplay animatronic wings that used the program for their design. But we really don’t want you to miss out if you’re doing mechanical design and need something like this, or just want to play around.

If you’d like to study up on your nuts and bolts, check out our primer on the ubiquitous four-bar linkage, or pore through Hackaday looking for other great linkage-powered examples, like this automatic hacksaw or a pantograph PCB probe for shaky hands.

Anyone know of an open-source linkage simulator that can also output STL files for 3D printing? Or in any format that could be easily transformed into OpenSCAD? Asking for a “friend”.

Continue reading “Amazing Mechanical Linkages and The Software to Design Them”

Build an Excellent Coffee Roaster With a Satisfyingly Low Price Tag

There’s a lot of mysticism around coffee roasting, but in the end it couldn’t be simpler. Take a bunch of beans, heat them up evenly, and stop before they get burned. The rest is details.

And the same goes for coffee roasters. The most primitive roasting technique involves stirring the beans in a pan or wok to keep them from scorching on the bottom. This works great, but it doesn’t scale. Industrial drum roasters heat a rotating drum with ridges on the inside like a cement mixer to keep the beans in constant motion while they pass over a gas fire. Fluidized-bed roasters use a strong stream of heated air to whirl the beans around while roasting them evenly. But the bottom line is that a coffee roaster needs to agitate the beans over a controllable heat source so that they roast as evenly as possible.

My DIY coffee roaster gave up the ghost a few days ago and I immediately ordered the essential replacement part, a hot air popcorn popper, to avert a true crisis: no coffee! While I was rebuilding, I thought I’d take some pictures and share what I know about the subject. So if you’re interested in roasting coffee, making a popcorn popper into a roaster, or even just taking an inside look at a thoroughly value-engineered kitchen machine, read on!

Continue reading “Build an Excellent Coffee Roaster With a Satisfyingly Low Price Tag”

Great People and Culture at 34th Chaos Communication Congress

If you’ve been to a Chaos Communication Congress, you know the feeling — the strange realization after it’s all over that you’re back in the “real world”. It’s somehow alienating and unfriendly in comparison to being surrounded by computer freaks, artists, hackers, activists, coders, and other like-minded individuals over the four days of the Congress. A hand-written poster by the podcasting center read “Endlich, normale Leute” — “At last, normal people” — which is irony piled on irony but the sentiment is still right for certain strange values of “normal”. Normal hackers? You’d probably fit right in.

We cover a lot of the talks from the Congress, because they’re first-class and because you can play along at home, but the real soul of the Congress is people getting together, making something temporary and crazy, talking over their common plans, learning new things directly from one-another, and simply having fun. Here’s our chance to give you a little of the other side of the Congress.
Continue reading “Great People and Culture at 34th Chaos Communication Congress”

34C3: Hacking into a CPU’s Microcode

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.

34C3: The First Day is a Doozy

It’s 5 pm, the sun is slowly setting on the Leipzig conference center, and although we’re only halfway through the first day, there’s a ton that you should see. We’ll report some more on the culture of the con later — for now here’s just the hacks. Continue reading “34C3: The First Day is a Doozy”