Warnings Are Your Friend – A Code Quality Primer

November 6, 2018 by Sven Gregori 63 Comments

If there’s one thing C is known and (in)famous for, it’s the ease of shooting yourself in the foot with it. And there’s indeed no denying that the freedom C offers comes with the price of making it our own responsibility to tame and keep the language under control. On the bright side, since the language’s flaws are so well known, we have a wide selection of tools available that help us to eliminate the most common problems and blunders that could come back to bite us further down the road. The catch is, we have to really want it ourselves, and actively listen to what the tools have to say.

We often look at this from a security point of view and focus on exploitable vulnerabilities, which you may not see as valid threat or something you need to worry about in your project. And you are probably right with that, not every flaw in your code will lead to attackers taking over your network or burning down your house, the far more likely consequences are a lot more mundane and boring. But that doesn’t mean you shouldn’t care about them.

Buggy, unreliable software is the number one cause for violence against computers, and whether you like it or not, people will judge you by your code quality. Just because Linus Torvalds wants to get off Santa’s naughty list, doesn’t mean the technical field will suddenly become less critical or loses its hostility, and in a time where it’s never been easier to share your work with the world, reliable, high quality code will prevail and make you stand out from the masses.

Continue reading “Warnings Are Your Friend – A Code Quality Primer” →

How The Sony PlayStation Was Hacked

November 5, 2018 by Drew Littrell 34 Comments

Playgrounds were the comment sections of their day. Every weekday from exactly 1:17 PM until 1:43 PM there were swings to be swung, rumors to be spread, and debates to be settled by whomever was the loudest (some things never change). Allegiances were formed and battle lines were drawn based solely on what video game console you supported. It was this playground system that perpetuated the urban myths of the time.

For PlayStation fans there was the myth that you could save Aerith from her fate in Final Fantasy VII if you just cast the right spell, or the secret code in Tomb Raider that would let you see all of Lara Croft. There was the myth that no one could possibly copy a PlayStation game because all the bottoms of the discs were black. Even the very existence of the first PlayStation, the Super Nintendo PlayStation prototype, was an urban legend. The difference was that last one turned out to be true.

Let’s jump in and take a look at the cat and mouse game between modchip makers looking to defeat the original PlayStation’s copy protection, and Sony’s efforts to protect their castle.
Continue reading “How The Sony PlayStation Was Hacked” →

The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel

November 2, 2018 by Sean Boyce 63 Comments

Have you ever had one of those moments, when you’re rummaging through your spare parts heap, and have a rather bizarre project idea that you can’t quite get out of your head? You know, the ones that have no clear use, but simply demand to be born, of glass and steel and silicon?

This time, the stubborn idea in question was sort of like a solar-rechargeable LED throwie, but instead of a blinking light, it has a fully cloud-accessible embedded Linux server in the form of a Raspberry Pi 3 Model B+. Your choice of embedded Linux board should work — I just happen to have a lot of these due to a shipping error.

There were two main challenges here: First, it would have to combine the smallest practical combination of solar panel, power supply, and Li-ion cell that could run the Raspberry Pi. Second, we’ll need to remotely activate and access the Pi regardless of where it is, as well as be able to connect it to WiFi without direct physical access. In this article we’ll be dealing with the first set of problems — stay tuned for the rest.

Continue reading “The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel” →

Hands On With The Arduino FPGA

November 1, 2018 by Al Williams 31 Comments

All of the tools you need to work with the FPGA Arduino — the Vidor — are now in the wild!

We reported earlier that a series of French blog posts finally showed how all the pieces fit together to program the FPGA on the Arduino MKR4000 Vidor board. Of course, I wasn’t content to just read the Google translation, I had to break out the board and try myself.

I created a very simple starter template, a tool in C to do the bitstream conversion, required, and bundled it all together in one place. Here’s how you can use my starter kit to do your own FPGA designs using the Vidor. I’m going to assume you know about FPGA basics and Verilog. If you don’t, why not check out the FPGA boot camps first?

The first thing you’ll want to do is grab my GitHub repo. You’ll also need the Arduino IDE (a recent copy) and Intel’s Quartus software. Inside, you’ll find three directories, two of which contain slightly modified copies of original Arduino files. But before you start digging in, let’s get the high-level overview of the process.

Continue reading “Hands On With The Arduino FPGA” →

When Good Software Goes Bad: Malware In Open Source

October 31, 2018 by Jonathan Bennett 28 Comments

Open Source software is always trustworthy, right? [Bertus] broke a story about a malicious Python package called “Colourama”. When used, it secretly installs a VBscript that watches the system clipboard for a Bitcoin address, and replaces that address with a hardcoded one. Essentially this plugin attempts to redirects Bitcoin payments to whoever wrote the “colourama” library.

Why would anyone install this thing? There is a legitimate package named “Colorama” that takes ANSI color commands, and translates them to the Windows terminal. It’s a fairly popular library, but more importantly, the name contains a word with multiple spellings. If you ask a friend to recommend a color library and she says “coulourama” with a British accent, you might just spell it that way. So the attack is simple: copy the original project’s code into a new misspelled project, and add a nasty surprise.

Sneaking malicious software into existing codebases isn’t new, and this particular cheap and easy attack vector has a name: “typo-squatting”. But how did this package get hosted on PyPi, the main source of community contributed goodness for Python? How many of you have downloaded packages from PyPi without looking through all of the source? pip install colorama? We’d guess that it’s nearly all of us who use Python.

It’s not just Python, either. A similar issue was found on the NPM javascript repository in 2017. A user submitted a handful of new packages, all typo-squatting on existing, popular packages. Each package contained malicious code that grabbed environment variables and uploaded them to the author. How many web devs installed these packages in a hurry?

Of course, this problem isn’t unique to open source. “Abstractism” was a game hosted on Steam, until it was discovered to be mining Monero while gamers were playing. There are plenty of other examples of malicious software masquerading as something else– a sizable chunk of my day job is cleaning up computers after someone tried to download Flash Player from a shady website.

Buyer Beware

In the open source world, we’ve become accustomed to simply downloading libraries that purport to do exactly the cool thing we’re looking for, and none of us have the time to pore through the code line by line. How can you trust them?

Repositories like PyPi do a good job of faithfully packaging the libraries and programs that are submitted to them. As the size of these repositories grow, it becomes less and less practical for every package to be manually reviewed. PyPi lists 156,750 projeccts. Automated scanning like [Bertus] was doing is a great step towards keeping malicious code out of our repositories. Indeed, [Bertus] has found eleven other malicious packages while testing the PyPi repository. But cleverer hackers will probably find their way around automated testing.

That the libraries are open source does add an extra layer of reliability, because the code can in principal be audited by anyone, anytime. As libraries are used, bugs are found, and features are added, more and more people are intentionally and unintentionally reviewing the code. In the “colourama” example, a long Base64 string was decoded and executed. It doesn’t take a professional researcher to realize something fishy is going on. At some point, enough people have reviewed a codebase that it can be reasonably trusted. “Colorama” has well over a thousand stars on Github, and 28 contributors. But did you check that before downloading it?

Typo-squatting abuses trust, taking advantage of a similar name and whoever isn’t paying quite close enough attention. It’s not practical for every user to check every package in their operating system. How, then, do we have any trust in any install? Cryptography solves some of these problems, but it cannot overcome the human element. A typo in a url, trusting a brand new project, or even obfuscated C code can fool the best of us from time to time.

What’s the solution? How do we have any confidence in any of our software? When downloading from the web, there are some good habits that go a long way to protect against attacks. Cross check that the project’s website and source code actually point to each other. Check for typos in URLs. Don’t trust a download just because it’s located on a popular repository.

But most importantly, check the project’s reputation, the number of contributors to the project, and maybe even their reputation. You wouldn’t order something on eBay without checking the seller’s feedback, would you? Do the same for software libraries.

A further layer of security can be found in using libraries supported by popular distributions. In quality distributions, each package has a maintainer that is familiar with the project being maintained. While they aren’t checking each line of code of every project, they are ensuring that “colorama” gets packaged instead of “colourama”. In contrast to PyPi’s 156,750 Python modules, Fedora packages only around 4,000. This selection is a good thing.

Repositories like PyPi and NPM are simply not the carefully curated sources of trustworthy software that we sometimes think them to be– and we should act accordingly. Look carefully into the project’s reputation. If the library is packaged by your distribution of choice, you can probably pass this job off to the distribution’s maintainers.

At the end of the day, short of going through the code line by line, some trust anchor is necessary. If you’re blindly installing random libraries, even from a “trustworthy” repository, you’re letting your guard down.

Kepler Closes Eyes After A Decade Of Discovery

October 30, 2018 by Tom Nardi 16 Comments

Since its launch in March 2009, the Kepler Space Telescope has provided us with an incredible amount of data about exoplanets within our galaxy, proving these worlds are more varied and numerous than we could ever have imagined. Before its launch we simply didn’t know how common planets such as ours were, but today we know the Milky Way contains billions of them. Some of these worlds are so hot they have seas of molten rock, others experience two sunsets a day as they orbit a pair of stars. Perhaps most importantly, thousands of the planets found by Kepler are much like our own: potentially playing host to life as we know it.

Kepler lived a fruitful life by any metric, but it hasn’t been an easy one. Too far into deep space for us to repair it as we did Hubble, hardware failures aboard the observatory nearly brought the program to a halt in 2013. When NASA announced the spacecraft was beyond hope of repair, most assumed the mission would end. Even by that point, Kepler was an unqualified success and had provided us with enough data to keep astronomers busy for years. But an ingenious fix was devised, allowing it to continue collecting data even in its reduced capacity.

Leaning into the solar wind, Kepler was able to use the pressure of sunlight striking its solar panels to steady itself. Kepler’s “eyesight” was never quite the same after the failure of its reaction wheels, and it consumed more propellant than originally intended to maintain this careful balancing act, but the science continued. The mission that had already answered many of our questions about our place in the galaxy would push ahead in spite of a failure which should have left it dead in space.

As Kepler rapidly burned through its supply of propellant, it became clear the mission was on borrowed time. It was a necessary evil, as the alternative was leaving the craft tumbling through space, but mission planners understood that the fix they implemented had put an expiration date on Kepler. Revised calculations could provide an estimate as to when the vehicle would finally run its tanks dry and lose attitude control, but not a definitive date.

For the last several months NASA has known the day was approaching, but they decided to keep collecting data until the vehicle’s thrusters sputtered and failed. So today’s announcement that Kepler has at long last lost the ability to orient itself came as no surprise. Kepler has observed its last alien sunset, but the search for planets, and indeed life, in our corner of the galaxy doesn’t end today.

Continue reading “Kepler Closes Eyes After A Decade Of Discovery” →

Relativity Space’s Quest To 3D Print Entire Rockets

October 30, 2018 by Tom Nardi 27 Comments

While the jury is still out on 3D printing for the consumer market, there’s little question that it’s becoming a major part of next generation manufacturing. While we often think of 3D printing as a way to create highly customized one-off objects, that’s a conclusion largely based on how we as individuals use the technology. When you’re building something as complex as a rocket engine, the true advantage of 3D printing is the ability to not only rapidly iterate your design, but to produce objects with internal geometries that would be difficult if not impossible to create with traditional tooling.

So it’s no wonder that key “New Space” players like SpaceX and Blue Origin make use of 3D printed components in their vehicles. Even NASA has been dipping their proverbial toe in the additive manufacturing waters, testing printed parts for the Space Launch System’s RS-25 engine. It would be safe to say that from this point forward, most of our exploits off of the planet’s surface will involve additive manufacturing in some capacity.

But one of the latest players to enter the commercial spaceflight industry, Relativity Space, thinks we can take the concept even farther. Not content to just 3D print rocket components, founders Tim Ellis and Jordan Noone believe the entire rocket can be printed. Minus electrical components and a few parts which operate in extremely high stress environments such as inside the pump turbines, Relativity Space claims up to 95% of their rocket could eventually be produced with additive manufacturing.

If you think 3D printing a rocket sounds implausible, you aren’t alone. It’s a bold claim, so far the aerospace industry has only managed to print relatively small rocket engines; so printing an entire vehicle would be an exceptionally large leap in capability. But with talent pulled from major aerospace players, a recently inked deal for a 20 year lease on a test site at NASA’s Stennis Space Center, and access to the world’s largest metal 3D printer, they’re certainly going all in on the idea. Let’s take a look at what they’ve got planned.

Continue reading “Relativity Space’s Quest To 3D Print Entire Rockets” →