32C3: 3D Printing on the Moon

How do you resist this talk title? You can’t! [Karsten Becker]’s talk about what kinds of 3D printers you’d use on the moon is a must-see.

[Part-Time Scientists] was a group of 35 people working on a mission to the moon. Then they won the qualifying round in the Google Lunar XPRIZE, got a bunch of money, and partnered with some heavy corporate sponsors, among which is Audi. Now they’ve added eleven full-time employees and updated the name to [PT Scientists]. (They’re taking applications if you’re interested in helping out!)

3d_printing_on_moon-shot0026A really neat part of their planned mission is to land near the Apollo 17 landing site, which will let them check up on the old lunar rover that NASA left up there last time. The science here is that, 45 years on, they hope to learn how all of the various materials that make up the rover have held up over time.

But the main attraction of their mission is experimental 3D printing using in-situ materials. As [Karsten] says, “3D printing is hard…but we want to do it on the moon anyway.”

3d_printing_on_moon-shot0027One idea is to essentially microwave the lunar regolith (and melt it) . This should work because there’s a decent iron component in the regolith, so if they can heat it up it should fuse. The catch with microwaving is directivity — it’s hard to make fine details. On the plus side, it should be easy to make structures similar to paved roads out of melted regolith. Microwave parts are robust and should hold up to launch, and microwaving is relatively energy efficient, so that’s what they’re going to go for.

But there are other alternatives. The European Space Agency is planning to bring some epoxy-like binder along, and glue regolith together in layers like a terrestrial cement printer. The problem is, of course, schlepping all of the binder to the moon in the first place.

And then there are lasers. [Karsten] talked lasers down a little bit, because they’re not very energy efficient and the optics are fidgety — not something you’d like to be supporting remotely from earth.

The final option that [Karsten] mentioned was the possibility of using locally-generated thermite to fuse regolith. This has been tested out on earth, and should work. [Karsten] thought it was an interesting option, but balls of hot thermite are potentially tough on rovers, and the cost of mistakes are so high that they’re going to put that off for a future mission.

In the end, the presentation ran only thirty minutes long, so there’s a great Q&A session after that. Don’t go home once you hear the audience clapping!

32C3: My Robot Will Crush You With Its Soft Delicate Hands!

In his talk at 32C3 [Matthew Borgatti] talked both about his company’s work with NASA toward developing robotic spacesuits and helping people with Cerebral Palsy better control their limbs. What do these two domains have in common? “One-size fits all pneumatic exoskeletons.”

[Matthew] makes a tremendously compelling case for doing something new and difficult in robotics — making robotic systems out of squishy, compliant materials. If you think about it, most robots are hard: made of metal and actuated by motors and gears, cables, or (non-compressible) pneumatic fluid. If you want to build suits that play well with soft and squishy people, they’ll need at least a layer of softness somewhere.

But [Matthew]’s approach is to make everything soft. In the talk, he mentions a few biological systems (octopus arms and goat’s feet) that work exactly because they’re soft. Why soft? Because soft spreads force around automatically and accommodates uneven terrain. And this makes it easier on the people who wear robotic suits and on the designers of the robots who don’t need to worry about the fine detail of the ground they’re walking on.

The talk ended up being very short, but there’s a fantastic Q&A at the end. It’s a must-see. And if you can’t get enough of [Matthew] or squishy robots, we’ve covered his robots before and he even had an entry in the Hackaday Prize.

32C3: So You Want to Build a Satellite?

[INCO] gave this extremely informative talk on building a CubeSat. CubeSats are small satellites that piggyback on the launches of larger satellites, and although getting a 10 cm3 brick into orbit is cheap, making it functional takes an amazing attention to detail and redundant design.

[INCO] somehow talks through the entire hour-long presentation at a tremendous speed, all the while remaining intelligible. At the end of the talk, you’ve got a good appreciation for the myriad pitfalls that go along with designing a satellite, and a lot of this material is relevant, although often in a simpler form, for high altitude balloon experiments.

satellite_2-shot0002CubeSats must be powered down during launch, with no radio emissions or anything else that might interfere with the rocket that’s carrying them. The satellites are then packed into a box with a spring, and you never see or hear from them again until the hatch is opened and they’re pushed out into space.

[INCO] said that 50% of CubeSats fail on deployment, and to avoid being one of the statistics, you need to thoroughly test your deployment mechanisms. Test after shaking, being heated and cooled, subject to low battery levels, and in a vacuum. Communication with the satellite is of course crucial, and [INCO] suggests sending out a beacon shortly after launch to help you locate the satellite at all.

satellite_2-shot0003Because your satellite is floating out in space, even tiny little forces can throw it off course. Examples include radiation pressure from the sun, and anything magnetic in your satellite that will create a torque with respect to the Earth’s magnetic field. And of course, the deployment itself may leave your satellite tumbling slightly, so you’re going to need to control your satellite’s attitude.

Power is of course crucial, and in space that means solar cells. Managing solar cells, charging lithium batteries, and smoothing out the power cycles as the satellite enters the earth’s shadow or tumbles around out of control in space. Frequent charging and discharging of the battery is tough on it, so you’ll want to keep your charge/discharge cycles under 20% of the battery’s nominal capacity.

mpv-shot0001In outer space, your satellite will be bombarded by heavy ions that can short-circuit the transistors inside any IC. Sometimes, these transistors get stuck shorted, and the only way to fix the latch-up condition is to kill power for a little bit. For that reason, you’ll want to include latch-up detectors in the power supply to reset the satellite automatically when this happens. But this means that your code needs to expect occasional unscheduled resets, which in turn means that you need to think about how to save state and re-synchronize your timing, etc.

In short, there are a ridiculous amount of details that you have to attend to and think through before building your own CubeSat. We’ve just scratched the surface of [INCO]’s advice, but if we had to put the talk in a Tweet, we’d write “test everything, and have a plan B whenever possible”. This is, after all, rocket science.

32C3: Running Linux On The PS4

At the 2010 Chaos Communication Congress, fail0verflow (that’s a zero, not the letter O) demonstrated their jailbreak of the PS3. At the 2013 CCC, fail0verflow demonstrated console hacking on the Wii U. In the last two years, this has led to an active homebrew scene on the Wii U, and the world is a better place. A few weeks ago, fail0verflow teased something concerning the Playstation 4. While this year’s announcement is just a demonstration of running Linux on the PS4, fail0verflow can again claim their title as the best console hackers on the planet.

Despite being able to run Linux, there are still a few things the PS4 can’t do yet. The current hack does not have 3D acceleration enabled; you won’t be playing video games under Linux with a PS4 any time soon. USB doesn’t work yet, and that means the HDD on the PS4 doesn’t work either. That said, everything to turn the PS4 into a basic computer running Linux – serial port, framebuffer, HDMI encoder, Ethernet, WiFi, Bluetooth, and the PS4 blinkenlights – is working.

Although the five-minute lightning talk didn’t go into much detail, there is enough information on their slides to show what a monumental task this was. fail0verflow changed 7443 lines in the kernel, and discovered the engineers responsible for the southbridge in the PS4 were ‘smoking some real good stuff’.

This is only fail0verflow’s announcement that Linux on the PS4 works, and the patches and bootstrap code are ‘coming soon’. Once this information is released, you’ll need to ‘Bring Your Own Exploit™’ to actually install Linux.

Video of the demo below.

Continue reading “32C3: Running Linux On The PS4”

32C3: Dieselgate — Inside the VW’s ECU

[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.

[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.

As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.

[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)

The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.

Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.

And if you’re interested in our other coverage of the Congress, we have quite a collection going already.

32C3: Inside Glorious Leader’s Operating System

North Korea is a surveillance state propped up by a totalitarian government infamous for human rights abuses and a huge military that serves the elite while the poor are left to fight over scraps. Coincidently, that’s exactly what North Korea says about the United States.

There is one significant difference between the two countries: North Korea has developed its own operating system for its citizens, called Red Star OS. It’s an operating system based on Linux, but that has a few interesting features that allow Glorious Leader to take care of his citizens. A deep teardown of what has gone into the development of Red Star OS hasn’t been available until now, with [Florian Grunow] and [Niklaus Schiess]’s talk at the Chaos Communication Congress this week.

Kim Jong-Un with an iMac
Kim Jong-Un with an iMac

The first question anyone must ask when confronted with an operating system built by a country that doesn’t have much electricity is, “why?” This question can only be answered philosophically; the late Kim Jong-Il stressed the importance of North Korea developing “their own style” of programming, and not relying on western operating systems. Nearly everything in Red Star has been modified, with a custom browser called Naenara, a crypto tool, a clone of Open Office, a software manager, and a custom music composition tool. Red Star also had to have the look and feel of OS X; that is, after all, what Glorious Leader uses.

Red Star goes much deeper than custom browsers and a desktop theme. There are other, subtler components inside the OS. There is a program that verifies the integrity of the system by checking signatures of the custom files against a database. If a file has been tampered with, the system reboots. Since this tamper check runs on bootup, Red Star makes it nearly impossible to modify files for study. This is one of the big features designed into Red Star – system integrity is paramount.

There are other custom bits of software that hide files from the user even if they have root, and a ‘virus scanner’ that is anything but. This virus scanner checks documents for patterns that, when put through Google Translate, are strange, weird, and somewhat understandable. Phrases like, “punishment”, “hungry”, and “strike with fists” are detected in all documents, and depending on what the developers decide, these documents can be deleted on a whim.

While scanning a system for documents that contain non-approved speech is abhorrent enough, there’s another feature that would make any privacy advocate weep. Media files including DOCX, JPG, PNG, and AVI files are watermarked by every computer that opened the files. This allows anyone to track the origin of a file, with the obvious consequences to free speech that entails.

While most people in the US consider North Korea to be a technological backwater and oppressive regime, the features that make Red Star OS useful to the DPRK are impressive. The developers touched nearly everything in Red Star, and the features inside it are rather clever and make their style of surveillance very useful. They’re also doing this without any apparent backdoors or other spycraft; they’re putting all their surveillance out in the open for all to see, which is, perhaps, the best way to go about it.

32C3: Shopshifting — Breaking Credit Card Payment Systems

Credit card payment systems touch all of our lives, and because of this there’s a lot riding on the security of that technology. The best security research looks into a widely deployed system and finds the problems before the bad guys do. The most entertaining security presentations end up finding face-palmingly bad practices and having a good laugh along the way. The only way to top that off is with live demos. [Karsten Nohl], [Fabian Bräunlein], and [dexter] gave a talk on the security of credit-card payment systems at the 32nd annual Chaos Communications Congress (32C3) that covers all the bases.

While credit card systems themselves have been quite well-scrutinized, the many vendor payment networks that connect the individual terminals haven’t. The end result of this research is that it is possible to steal credit card PINs and remotely refund credits to different cards — even for purchases that have never been made. Of course, the researchers demonstrate stealing money from themselves, but the proof of concept is solid. How they broke two separate payment systems is part hardware hacking, part looking-stuff-up-on-the-Internet, and part just being plain inquisitive.

Continue reading “32C3: Shopshifting — Breaking Credit Card Payment Systems”