Deciphering Queen Of Scots, Mary Stuart’s Lost Letters

February 12, 2023 by Maya Posch 10 Comments

First part of the cypher used by Mary Stuart and Castelnau, showing the use of homophones, special characters and more. (Credit: Lasry et al., 2023)

Communications by important people over the past thousands of years have been regularly encrypted, making the breaking of this encryption both an essential and also a fascinating historical field. One recent example of an important historical discovery by codebreakers are letters dating back to 1578 through 1584 by Mary Stuart, the Queen of Scots in the 16th century. While deemed lost for centuries, researchers came across them in a stash of encrypted letters that were kept at the Bibliothèque nationale de France’s (BnF). After decrypting these 57 letters, they realized what they had come across.

Even in digitized form, they could not simply be OCRed, leaving the researchers to manually transcribe each character into the software they used to assist with the decrypting. Only during the decrypting process, they began to realize that these were not Italian communications – matching the rest of the collection of which they were part – but in fact letters by Mary and her allies. Of the 57 letters, 54 are from Mary to Castelnau, the French ambassador in London at the time.

Supporting evidence for these decrypted letters being from Mary and Castelnau came from British archives, which had clear text versions of some of the encrypted letters, dated to the years when a mole within the French embassy was leaking translated texts to the English, as part of the usual political pastime during those centuries of getting onto thrones and making other people leave them. Mary’s attempt to become not only the Queen of Scots but also Queen of England came to a tragic end with her execution in 1587 after a politically motivated show trial.

The software the researchers used primarily is called CrypTool 2, which is an open-source project that provides cryptoanalysis and related functionality. The access to the documents themselves was enabled via the DECRYPT project, resources which taken together enables virtually anyone to undertake such historical sleuthing from the comfort of their own home.

(Thanks to [Stephen Walters] for the tip)

Hacking D-Link Firmware

August 24, 2020 by Al Williams 15 Comments

When [0xRickSanchez] found some D-Link firmware he couldn’t unpack, he was curious to find out why. The firmware had a new encryption method which was doing its job of preventing tampering and static analysis. Of course, he had to figure out how to get around it and is documenting his work in a series of blog posts.

Looking at the entropy analysis showed the data to be totally random, a good sign it was either encrypted or compressed. The target router cost about $200, but a similar cheaper router used the same encryption and thus this model became the hardware of choice for testing.

Continue reading “Hacking D-Link Firmware” →

Researchers Break FPGA Encryption Using FPGA Encryption

April 23, 2020 by Elliot Williams 18 Comments

FPGAs are awesome — they can be essentially configured into becoming any computing device you want. Simply load your selected bitstream into the device on boot, and it behaves like a different piece of hardware. With great power comes great responsibility.

You might try to hack a given FPGA system by getting between the EEPROM that stores the bitstream and the FPGA during bootup, but FPGA manufacturers are a step ahead of you. Xilinx 7 series FPGAs have an onboard encryption and signing engine, and facilities for storing a secret key. Once the security bit is set, bitstreams coming in have to be encrypted to protect from eavesdropping, and HMAC-signed to assure that they are authentic. You can’t simply read the bitstream in transit or inject your own.

Researchers at Ruhr University Bochum and Max Planck Institute for Cybersecurity and Privacy in Germany have figured out a way to use the FPGA’s own encryption engine against itself to break both of these security guarantees for the entire mainstream 7-series. The attack abuses a MultiBoot function that allows you to specify an address to begin execution after reboot. The researchers send 32 bits of the encoded payload as a MultiBoot address, the FPGA decrypts it and stores it in a register, and then resets because their command wasn’t correctly HMAC signed. But because the WBSTAR register is meant to be readable on boot after reset, the payload is still there in its decrypted form. Repeat for every 32 bits in the bitstream, and you’re done.

Pulling off this attack requires physical access to the FPGA’s debug pins and up to 12 hours, so you only have to worry about particularly dedicated adversaries, but the results are catastrophic — if you can reconfigure an FPGA, you can make it do essentially anything. Security-sensitive folks, we have three words of consolation for you: “restrict physical access”.

What does this mean for Hackaday? If you’re looking at a piece of hardware with a hardened Xilinx 7-series FPGA in it, you’ll be able to use it, although it’s horribly awkward for debugging due to the multi-hour encryption procedure. Anyone know of a good side-channel bootloader for these chips? On the other hand, if you’re just looking to dig secrets out from the bitstream, this is a one-time cost.

This hack is probably only tangentially relevant to the Symbiflow team’s effort to reverse-engineer an open-source toolchain for this series of FPGAs. They are using unencrypted bitstreams for all of their research, naturally, and are almost done anyway. Still, it widens the range of applicability just a little bit, and we’re all for that.

[Banner image is a Numato Lab Neso, and comes totally unlocked naturally.]

DRM Workarounds Save Arcade Cabinet

December 19, 2017 by Bryan Cockfield 31 Comments

DRM has become a four-letter word of late, with even media companies themselves abandoning the practice because of how ineffective it was. DRM wasn’t invented in the early 2000s for music, though. It’s been a practice on virtually everything where software is involved, including arcade cabinets. This is a problem for people who restore arcade machines, and [mon] has taken a swing at unraveling the DRM for a specific type of Konami cabinet.

The game in question, Reflec Beat, is a rhythm-based game released in 2010, and the security is pretty modern. Since the game comes with a HDD, a replacement drive can be ordered with a security dongle which acts to decrypt some of the contents on the HDD, including the game file and some other information. It’s not over yet, though. [mon] still needs to fuss with Windows DLL files and a few levels of decryption and filename obfuscation before getting the cabinet functional again.

The writeup on this cabinet is very detailed, and if you’re used to restoring older games, it’s a bit of a different animal to deal with than the embedded hardware security that older cabinets typically have. If you’ve ever wanted to own one of these more modern games, or you’re interested in security, be sure to check out the documentation on the project page. If your tastes are more Capcom and less Konami, check out an article on their security system in general, or in de-suiciding boards with failing backup batteries.

Apple’s Secure Enclave Processor (SEP) Firmware Decrypted

August 18, 2017 by Jack Laidlaw 14 Comments

The decryption key for Apple’s Secure Enclave Processor (SEP) firmware Posted Online by self-described “ARM64 pornstar” [xerub]. SEP is the security co-processor introduced with the iPhone 5s which is when touch ID was introduced. It’s a black box that we’re not supposed to know anything about but [xerub] has now pulled back the curtain on that.

The secure enclave handles the processing of fingerprint data from the touch ID sensor and determines if it is a match or not while it also enables access for purchases for the user. The SEP is a gatekeeper which prevents the main processor from accessing sensitive data. The processor sends data which can only be read by the SEP which is authenticated by a session key generated from the devices shared key. It also runs on its own OS [SEPOS] which has a kernel, services drivers and apps. The SEP performs secure services for the rest of the SOC and much more which you can learn about from the Demystifying the Secure Enclave Processor talk at Blackhat

[xerub] published the decryption keys here. To decrypt the firmware you can use img4lib and xerub’s SEP firmware split tool to process. These tools make it a piece of cake for security researchers to comb through the firmware looking for vulnerabilities.

Paper Enigma Machine

April 2, 2016 by Elliot Williams 6 Comments

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!)

7400 Project Encrypts And Decrypts Data

October 15, 2012 by Mike Szczys 8 Comments

[Nakul], [Nikilesh], and [Nischal] just finished posting about their entry in the 2012 Open 7400 Logic competition. It’s an encryption system based entirely on 7400 logic chips. The device operates on 8-bit binary numbers, which limits its real-world applications. But we bet they learned a lot during the development process.

The encryption algorithm is based on a the concept of cellular automaton. This is a something with which we’re already familiar having seen many Conway’s Game of Life projects around here. What we’re not familiar with is this particular wing of the concept called ‘Rule 30‘. It works well with this project because a complex pattern can be generated from simple beginnings.

After conceptualizing how the system might work the team spent some time transferring the implementation to the chips they had available. The end result is a quartet of chip-packed breadboards and a rat’s nets of wires, but the system is capable of both encrypting and decrypting data.