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: 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: 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: Vector Video Games

There are a few classic video games that rely on vector graphics and special monitors. Asteroids is incomplete if you’re not playing it in its original arcade format. The same goes with Tempest, Lunar Lander, and the 1983 Star Wars arcade game. Emulation of these games is possible, even with MAME, but the display – like every display you can buy today – is still rasterized. The solution to this problem is to create a vector display output for MAME that works in conjunction with adapter boards and DACs connected to a monitor.

For this year’s Chaos Computer Congress, that’s exactly what [Trammell Hudson] and [Adelle Lin] did. They’ve created an open source vector gaming system that connects MAME to XY monitors and oscilloscopes.

The build uses a custom board equipped with a Teensy 3.1 microcontroller and a 12-bit DAC to convert XY coordinates sent by MAME to vectors that can be displayed on any XY monitor. This, of course, requires a patch to MAME, which the maintainers rejected as being an, “unacceptably hacky way to achieve the intended result.” It does achieve the intended result, though: allowing dozens of vector games playable on whatever monitor supports vector graphics.

So far, [Trammell] and [Adelle] have gotten their system working on Vectrex consoles, analog oscilloscopes set to XY mode, and vectorscopes that litter every broadcast station and surplus shop. Check out [Trammell] and [Adelle]’s talk, and if you want to build the V.st vector display driver, the board is available from OSHPark.

32C3: A Free and Open Source Verilog-to-Bitstream Flow for iCE40 FPGAs

[Clifford] presented a fully open-source toolchain for programming FPGAs. If you don’t think that this is an impressive piece of work, you don’t really understand FPGAs.

The toolchain, or “flow” as the FPGA kids like to call it, consists of three parts: Project IceStorm, a low-level tool that can build the bitstreams that flip individual bits inside the FPGA, Arachne-pnr, a place-and-route tool that turns a symbolic netlist into the physical stuff that IceStorm needs, and Yosys which synthesizes Verilog code into the netlists needed by Arachne. [Clifford] developed both IceStorm and Yosys, so he knows what he’s talking about.

What’s most impressive is that FPGAs aren’t the only target for this flow. Because it’s all open source and modifiable, it has also been used for designing custom ASICs, good to know when you’re in need of your own custom silicon. [Clifford]’s main focus in Yosys is on formal verification — making sure that the FPGA will behave as intended in the Verilog code. A fully open-source toolchain makes working on this task possible.

If you’ve been following along with [Al Williams]’s FPGA posts, either this introduction or his more recent intermediate series that are also based on the relatively cheap Lattice iCEStick development kit, this video is a must-watch. It’s a fantastic introduction to the cutting-edge in free FPGA tools.

32C3: Towards Trustworthy x86 Laptops

Security assumes there is something we can trust; a computer encrypting something is assumed to be trustworthy, and the computer doing the decrypting is assumed to be trustworthy. This is the only logical mindset for anyone concerned about security – you don’t have to worry about all the routers handling your data on the Internet, eavesdroppers, or really anything else. Security breaks down when you can’t trust the computer doing the encryption. Such is the case today. We can’t trust our computers.

In a talk at this year’s Chaos Computer Congress, [Joanna Rutkowska] covered the last few decades of security on computers – Tor, OpenVPN, SSH, and the like. These are, by definition, meaningless if you cannot trust the operating system. Over the last few years, [Joanna] has been working on a solution to this in the Qubes OS project, but everything is built on silicon, and if you can’t trust the hardware, you can’t trust anything.

And so we come to an oft-forgotten aspect of computer security: the BIOS, UEFI, Intel’s Management Engine, VT-d, Boot Guard, and the mess of overly complex firmware found in a modern x86 system. This is what starts the chain of trust for the entire computer, and if a computer’s firmware is compromised it is safe to assume the entire computer is compromised. Firmware is also devilishly hard to secure: attacks against write protecting a tiny Flash chip have been demonstrated. A Trusted Platform Module could compare the contents of a firmware, and unlock it if it is found to be secure. This has also been shown to be vulnerable to attack. Another method of securing a computer’s firmware is the Core Root of Trust for Measurement, which compares firmware to an immutable ROM-like memory. The specification for the CRTM doesn’t say where this memory is, though, and until recently it has been implemented in a tiny Flash chip soldered to the motherboard. We’re right back to where we started, then, with an attacker simply changing out the CRTM chip along with the chip containing the firmware.

But Intel has an answer to everything, and to the house of cards for firmware security, Intel introduced their Management Engine. This is a small microcontroller running on every Intel CPU all the time that has access to RAM, WiFi, and everything else in a computer. It is security through obscurity, though. Although the ME can elevate privileges of components in the computer, nobody knows how it works. No one has the source code for the operating system running on the Intel ME, and the ME is an ideal target for a rootkit.

trustedstickIs there hope for a truly secure laptop? According to [Joanna], there is hope in simply not trusting the BIOS and other firmware. Trust therefore comes from a ‘trusted stick’ – a small memory stick that contains a Flash chip that verifies the firmware of a computer independently of the hardware in a computer.

This, with open source firmwares like coreboot are the beginnings of a computer that can be trusted. While the technology for a device like this could exist, it will be a while until something like this will be found in the wild. There’s still a lot of work to do, but at least one thing is certain: secure hardware doesn’t exist, but it can be built. Whether secure hardware comes to pass is another thing entirely.

You can watch [Joanna]’s talk on the 32C3 streaming site.

23 Superconference Talks You Shouldn’t Miss

November marked our inaugural Hackaday Superconference, something we’ve been wanting to do for a very long time. Hackaday already has a massive and vibrant online community, but until now, we haven’t asked people to come together for a hardware conference that spans a full weekend. The Supercon is Hackaday incarnate, and hundreds of very cool people showed up for a few dozen talks, amazing workshops, and a lot more.

Over the past month, we’ve been putting together a compilation of everything that happened at the first Hackaday Superconference. This includes videos of all the talks, relevant asides, and posts for everything that happened over a two-day conference. Even if you couldn’t make it out to our first con, this great material that should be shared by all.

Below is a YouTube playlist of all the talks. If you’re looking for eight hours to kill over the holiday weekend, well, there you have it. After the break is the complete conference indexed by day and speaker, with links to the talk and accompanying Hackaday post.

We’d like to thank everyone who came out to the first Hackaday Supercon, with a huge shout-out to the speakers, workshop organizers, and volunteers. It couldn’t have happened without the full support of the Hackaday community. That’s good, because we’re going to be doing this again next year.

Continue reading “23 Superconference Talks You Shouldn’t Miss”