software

135 Articles

Mini Falcon 9 Uses NASA Software

July 26, 2022 by 17 Comments

[T-Zero Systems] has been working on his model Falcon 9 rocket for a while now. It’s an impressive model, complete with thrust vectoring, a microcontroller which follows a predetermined flight plan, a working launch pad, and even legs to attempt vertical landings. During his first tests of his model, though, there were some issues with the control system software that he wrote so he’s back with a new system that borrows software from the Space Shuttle.

The first problem to solve is gimbal lock, a problem that arises when two axes of rotation line up during flight, causing erratic motion. This is especially difficult because this model has no ability to control roll. Solving this using quaternion instead of Euler angles involves a lot of math, provided by libraries developed for use on the Space Shuttle, but with the extra efficiency improvements the new software runs at a much faster rate than it did previously. Unfortunately, the new software had a bug which prevented the parachute from opening, which wasn’t discovered until after launch.

There’s a lot going on in this build behind-the-scenes, too, like the test rocket motor used for testing the control system, which is actually two counter-rotating propellers that can be used to model the thrust of a motor without actually lighting anything on fire. There’s also a separate video describing a test method which validates new hardware with data from prior launches. And, if you want to take your model rocketry further in a different direction, it’s always possible to make your own fuel as well.

Continue reading “Mini Falcon 9 Uses NASA Software” →

Ortur Laser Will Go Open-Source

July 18, 2022 by 76 Comments

Well, that was fast! Last week, we wrote about a video by [Norbert Heinz] where he called out the Ortur laser engravers for apparently using the GPL-licensed grbl firmware without providing the source code and their modifications to it, as required by the license. Because open source and grbl are dear to our hearts and CNC machines, we wrote again about Norbert’s efforts over the weekend, speculating that it might just be unfamiliarity with the open source license requirements on Ortur’s part.

Because of [Norbert]’s persistance and publicity around the issue, the support ticket finally reached the right person within Ortur, and within two or three days [Gil Araújo], Support Admin at Ortur, managed to convince the company that going fully open source was the right thing to do. What remains is the question of how to do it, operationally.

So [Gil] asked [Norbert] to ask Hackaday: what do you want from Ortur on this, and how should they proceed? Via e-mail, he asked in particular for best practices on setting up the repository and making the code actually useful to non-programmer types. He said that he looked around at the other laser engraver companies, and didn’t find any good examples of others doing the Right Thing™, so he asked [Norbert] to ask us. And now we’re asking you!

Have you got any good examples of companies using open-source firmware, modifying it, and making it available for their users? Is a simple Github repo with a README enough, or should he spend some time on making it user-friendly for the non-coders out there? Or start with the former and work toward the latter as a goal? I’m sure [Gil] will be reading the comments, so be constructive! You’ll be helping a laser engraver company take its first steps into actually engaging with the open source community.

We said it before, and we’ll say it again. Good job [Norbert] for taking Ortur to task here, but also by doing so in a way that leaves them the option of turning around and doing the right thing. This also highlights that companies aren’t monolithic beasts – sometimes it takes getting your cause heard by just the right person within a company to change the response from a “this is a business secret” to “how should we set up our Github?” And kudos for [Gil] and Ortur for listening to their users!

Fighting The Good Fight

July 16, 2022 by 21 Comments

We here at Hackaday are super-duper proponents of open source. Software, hardware, or firmware, we like to be able to see it, learn from it, modify it, and make it ourselves. Some of this is self-serving because when we can’t see how it was done, we can’t show you how it’s done. But it’s also from a deeper place than that: the belief that the world is made better by sharing and open access.

One of the pieces of open-source firmware that I have running on no fewer than three devices in my house right now is grbl – it’s a super-simple, super-reliable G-code interpreter and stepper motor controller that has stood the test of time. It’s also GPL3 licensed, which means that if you want to use the code in your project, and you modify it to match your particular machine, you have to make the modified version available for those who bought the machine to modify themselves.

So when Norbert Heinz noticed that the Ortur laser engravers were running grbl without making the code available, he wrote them a letter. They responded with “business secrets”, he informed them again of their responsibility, and they still didn’t comply. So he made a video explaining the situation.

Good news incoming! Norbert wrote in the comments that since the post hit Hackaday, they’ve taken notice over at Ortur and have gotten back in touch with him. Assuming that they’re on their way to doing the right thing, this could be a nice win for grbl and for Ortur users alike.

Inside the free software world, we all know that “free” has many meanings, but I’d bet that you don’t have to go far outside our community to find people who don’t know that “free” software can have tight usage restrictions on it. (Or maybe not – it all depends on the license that the software’s author chose.) Reading software licenses is lousy work better left for lawyers than hackers anyway, and I can no longer count how many times I’ve clicked on a EULA without combing through it.

So what Norbert did was a good deed – educating a company that used GPL software of their obligations. My gut says that Ortur had no idea what they needed to do to comply with the license, and Norbert told them, even if it required some public arm-twisting. But now, Ortur has the opportunity to make good, and hackers everywhere can customize the firmware that drives their laser engravers. Woot!

It’s probably too early to declare victory here, but consider following Norbert’s example yourself. While you can’t bring a lawsuit if you’re not the copyright owner, you can still defend your right to free software simply by explaining it politely to companies that might not know that they’re breaking the law. And when they come around, make sure you welcome them into the global open-source hive mind, because we all win. One of us!

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Why You Should Totally Roll Your Own AES Cryptography

July 11, 2022 by 27 Comments

Software developers are usually told to ‘never write your own cryptography’, and there definitely are sufficient examples to be found in the past decades of cases where DIY crypto routines caused real damage. This is also the introduction to [Francis Stokes]’s article on rolling your own crypto system. Even if you understand the mathematics behind a cryptographic system like AES (symmetric encryption), assumptions made by your code, along with side-channel and many other types of attacks, can nullify your efforts.

So then why write an article on doing exactly what you’re told not to do? This is contained in the often forgotten addendum to ‘don’t roll your own crypto’, which is ‘for anything important’. [Francis]’s tutorial on how to implement AES is incredibly informative as an introduction to symmetric key cryptography for software developers, and demonstrates a number of obvious weaknesses users of an AES library may not be aware of.

This then shows the reason why any developer who uses cryptography in some fashion for anything should absolutely roll their own crypto: to take a peek inside what is usually a library’s black box, and to better understand how the mathematical principles behind AES are translated into a real-world system. Additionally it may be very instructive if your goal is to become a security researcher whose day job is to find the flaws in these systems.

Essentially: definitely do try this at home, just keep your DIY crypto away from production servers :)

Think You Know How Mario Kart Works?

July 4, 2022 by 3 Comments

In what looks like the kickoff of a fun video series, [MrL314] takes us on a quick but deep tour of how the AI in Mario Kart works. (Video, embedded below.) Don’t play much Mario Kart anymore? Well, have a look anyway because some of the very simple tricks that make Bowser pass Princess Peach without running into her might be useful in any manner of pre-programmed navigation scenarios.

Quick spoilers. The CPU players move through different zones, each with a desired speed and a vector direction field that changes the direction they should point in. Only when they run off course do they actually compute headings to their target. Setting this desired direction and speed beforehand greatly reduces the on-the-fly computation needed.

Then you throw other players into the mix, and a very simple distance-dependant turning algorithm makes for clean overtaking. This effect is hand-tweaked for the particular racecourse, though, because you don’t want Luigi driving off the thin stretches on Rainbow Road. For more technical details, you can check out [MrL314]’s notes.

If anything, this video gives us a further appreciation of the clever little hacks that create apparently complex interactions from tremendously simple rules. Remember Mario Kart when you’re programming in that next multi-gigabyte neural network model, OK?

Continue reading “Think You Know How Mario Kart Works?” →

Linux Fu: Roll With The Checksums

June 22, 2022 by 14 Comments

We are often struck by how often we spend time trying to optimize something when we would be better off just picking a better algorithm. There is the old story about the mathematician Gauss who, when in school, was given busy work to add the integers from 1 to 100. While the other students laboriously added each number, Gauss realized that 100+1 is 101 and 99 + 2 is also 101. Guess what 98 + 3 is? Of course, 101. So you can easily find that there are 50 pairs that add up to 101 and know the answer is 5,050. No matter how fast you can add, you aren’t likely to beat someone who knows that algorithm. So here’s a question: You have a large body of text and you want to search for it. What’s the best way?

Continue reading “Linux Fu: Roll With The Checksums” →

Who Is Thinking About Open Source Firmware?

May 14, 2022 by 23 Comments

Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.

Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.

With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.

Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.

And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.

This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.

How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!