Reverse Engineering An ST-Link Programmer

We’re not sure why [lujji] would want to hack ST’s ST-Link programmer firmware, but it’s definitely cool that he did, and his writeup is a great primer in hacking embedded devices in two parts: first he unpacks and decrypts the factory firmware and verifies that he can then upload his own encrypted firmware through the bootloader, and then he dumps the bootloader, figures out where it’s locking the firmware image, and sidesteps the protection.

[lujji]’s project was greatly helped out by having the firmware’s encryption keys from previous work by [Taylor Killian]. Once able to run his own code on an intact device, [lujji] wrote a quick routine that dumped the entire flash ROM contents out over the serial port. This gave him the bootloader binary, the missing piece in the two-part puzzle.

If you’ve ever broken copy protection of the mid-1990’s, you won’t be surprised what happened next. [lujji] located the routine where the bootloader adds in the read protection, and NOPped it out. After uploading firmware with this altered bootloader, [lujji] found that it wasn’t read-protected anymore. Game over!

We glossed over a couple useful tips and tricks along the way, so if you’re into reversing firmware, give [lujji]’s blog a look. If you just want a nice ARM programmer with UART capabilities, however, there’s no reason to go to these extremes. The Black Magic Probe project gives you equal functionality and it’s open source. Or given that the official ST-Link programmers are given away nearly free with every Nucleo board, just buying one is clearly the path of least resistance. But a nice hack like this is its own reward for those who want to take that path. Thanks, [lujji] for writing it up.

Crack Mike Tyson’s Punch Out Bang Bang Passwords

[Bisqwit] has feelings about games that use exclamation points in his idiosyncratic walkthrough of all the nuances of the passwords in the famous Punch Out Bang Bang.

As he states in his deeply weird (though in no way wrong) channel intro, when he’s not driving a bus or teaching Israeli dance, he works hard to understand the things around him. Naturally, a mysterious phone number shaped set of digits in a favorite game was a secret worth extracting.

The digits can represent every possible state in the game.  It uses a pretty simple decoding and encoding scheme, which he walks through. As he says, it all becomes clear when you can see the source code.

After working through all the quirks he is able to arbitrarily generate any state in the game and handle the exceptions (such as Nintendo USA’s phone number). You can see all his code here and try it out for yourself. Video after the break.

We’ve grown to respect [Bisqwit] as the explainer of all things console games. You will like his explanation of how to write a code emulator for an NES CPU.

Continue reading “Crack Mike Tyson’s Punch Out Bang Bang Passwords”

Taking A U2F Hardware Key From Design To Production

Building a circuit from prototyping to printed circuit board assembly is within the reach of pretty much anyone with the will to get the job done. If that turns out to be something that everyone else wants, though, the job gets suddenly much more complex. This is what happened to [Conor], who started with an idea to create two-factor authentication tokens and ended up manufacturing an selling them on Amazon. He documented his trials and tribulations along the way, it’s both an interesting and perhaps cautionary tale.

[Conor]’s tokens themselves are interesting in their simplicity: they use an Atmel ATECC508A specifically designed for P-256 signatures and keys, a the cheapest USB-enabled microcontroller he could find: a Silicon Labs EFM8UB1. His original idea was to solder all of the tokens over the course of one night, which is of course overly optimistic. Instead, he had the tokens fabricated and assembled before being shipped to him for programming.

Normally the programming step would be straightforward, but using identical pieces of software for every token would compromise their security. He wrote a script based on the Atmel chip and creates a unique attestation certificate for each one. He was able to cut a significant amount of time off of the programming step by using the computed values with a programming jig he built to flash three units concurrently. This follows the same testing and programming path that [Bob Baddeley] advocated for in his Tools of the Trade series.

From there [Conor] just needed to get set up with Amazon. This was a process worthy of its own novel, with Amazon requiring an interesting amount of paperwork from [Conor] before he was able to proceed. Then there was an issue of an import tariff, but all-in-all everything seems to have gone pretty smoothly.

Creating a product from scratch like this can be an involved process. In this case it sounds like [Conor] extracted value from having gone through the entire process himself. But he also talks about a best-case-scenario margin of about 43%. That’s a tough bottom line but a good lesson anyone looking at building low-cost electronics.

Encrypted USB Bootloader For AVRs

It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.

But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.

Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.

If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.

Shor’s Algorithm In Five Atoms

If you want to factor a number, one way to do it is Shor’s algorithm. That’s a quantum algorithm and finds prime factors of integers. That’s interesting because prime factorization is a big deal of creating or breaking most modern encryption techniques.

Back in 2001, a group at IBM factored 15 (the smallest number that the algorithm can factor) using a 7 qubit system that uses nuclear magnetic resonance. Later, other groups duplicated the feat using photonic qubits. Typical implementations take 12 qubits. However, recent work at MIT and the University of Innsbruck can do the same trick with 5 atoms caught in an ion trap. The researchers believe their implementation will easily scale to larger numbers.

Each qubit is an atom and LASER pulses perform the logic operations. By removing an electron to make each atom positively charged, an electric field can exactly hold the positively charged ions in position only microns apart.

We’ve covered quantum computing before. We’ve even talked about the effect of practical quantum computing on encryption. You might also want to read more about the algorithm involved.

Photo credit: Jose-Luis Olivares/MIT

Apple Aftermath: Senate Entertains A New Encryption Bill

If you recall, there was a recent standoff between Apple and the U. S. Government regarding unlocking an iPhone. Senators Richard Burr and Dianne Feinstein have a “discussion draft” of a bill that appears to require companies to allow the government to court order decryption.

Here at Hackaday, we aren’t lawyers, so maybe we aren’t the best source of legislative commentary. However, on the face of it, this seems a bit overreaching. The first part of the proposed bill is simple enough: any “covered entity” that receives a court order for information must provide it in intelligible form or provide the technical assistance necessary to get the information in intelligible form. The problem, of course, is what if you can’t? A covered entity, by the way, is anyone from a manufacturer, to a software developer, a communications service, or a provider of remote computing or storage.

There are dozens of services (backup comes to mind) where only you have the decryption keys and there is nothing reasonable the provider can do to get your data if you lose your keys. That’s actually a selling point for their service. You might not be anxious to backup your hard drive if you knew the vendor could browse your data when they wanted to do so.

The proposed bill has some other issues, too. One section states that nothing in the document is meant to require or prohibit a specific design or operating system. However, another clause requires that covered entities provide products and services that are capable of complying with the rule.

A broad reading of this is troubling. If this were law, entire systems that don’t allow the provider or vendor to decrypt your data could be illegal in the U. S. Whole classes of cybersecurity techniques could become illegal, too. For example, many cryptography systems use the property of forward secrecy by generating unrecorded session keys. For example, consider an SSH session. If someone learns your SSH key, they can listen in or interfere with your SSH sessions. However, they can’t take recordings of your previous sessions and decode them. The mechanism is a little different between SSHv1 (which you shouldn’t be using) and SSHv2. If you are interested in the gory details for SSHv2, have a look at section 9.3.7 of RFC 4251.

In all fairness, this isn’t a bill yet. It is a draft and given some of the definitions in section 4, perhaps they plan to expand it so that it makes more sense, or – at least – is more practical. If not, then it seems to be an indication that we need legislators that understand our increasingly technical world and have some understanding of how the new economy works. After all, we’ve seen this before, right? Many countries are all too happy to enact and enforce tight banking privacy laws to encourage deposits from people who want to hide their money. What makes you think that if the U. S. weakens the ability of domestic companies to make data private, that the business of concealing data won’t just move offshore, too?

If you were living under a rock and missed the whole Apple and FBI controversy, [Elliot] can catch you up. Or, you can see what [Brian] thought about Apple’s response to the FBI’s demand.

Paper Enigma Machine

It was high-tech encryption for an important period of time in the mid-1940s, so perhaps you can forgive us our obsession with the Enigma machine. But did you know that you can make your very own Enigma just using some cut out paper strips and a tube to wrap them around? Yeah, you probably did. But this one is historically accurate and looks good too!

If you just want to understand how the machine worked, having a bunch of paper rolls in your hands is a very intuitive approach. Alan Turing explained the way it worked with paper models too, so there’s no shame there. With this model, you can either make the simple version with fixed rotor codes, or cut out some extra slip rings and go all out.

What is it with Hackaday and the Enigma machine? Just last month, we covered two separate Enigma builds: one with a beautiful set of buttons and patch cables, and another in convenient wrist-watch format. In fact, one of our first posts was on a paper Enigma machine, but the links are sadly lost to bitrot. We figure it’s cool to repeat ourselves once every eleven years. (And this one’s in color!)