A Secure Phone Fit For A Prime Minister

The curtain of state secrecy which surrounds the type of government agency known primarily by initialisms is all-encompassing and long-lived, meaning that tech that is otherwise in the public domain remains top secret for many decades. Thus it’s fascinating when from time to time the skirts are lifted to reveal a glimpse of ankle, as has evidently been the case for a BBC piece dealing with the encrypted phones produced by GCHQ and used by Margaret Thatcher in the early 1980s. Sadly, it’s long on human interest and short on in-depth technology, but nevertheless from it can be deduced enough to work out how it most likely worked.

We’re told that it worked over a standard phone line and transmitted at 2.4 kilobytes per second, a digital data stream encoded using a paper tape key that was changed daily. If we were presented with this design spec to implement in a briefcase using 1980s components, we’d probably make an ADPCM (Adaptive Differential Pulse Code Modulation) system with an XOR encryption against the key, something we think would be well within the capabilities of early 1980s digital logic and microprocessors. We’re wondering whether the BBC have made a typo and that  should be kilobits rather than kilobytes to work on a standard phone line.

No doubt there are people in the comments who could tell us if they were willing to break the Official Secrets Act, but we’d suggest they don’t risk their liberty by doing so. It’s worth noting though, that GCHQ have been known to show off some of their past glories, as in this 2019 exhibition at London’s Science Museum.

Wireshark HTTPS Decryption

If you’ve done any network programming or hacking, you’ve probably used Wireshark. If you haven’t, then you certainly should. Wireshark lets you capture and analyze data flowing over a network — think of it as an oscilloscope for network traffic. However, by design, HTTPS traffic doesn’t give up its contents. Sure, you can see the packets, but you can’t read them — that’s one of the purposes of HTTPS is to prevent people snooping on your traffic from reading your data. But what if you are debugging your own code? You know what is supposed to be in the packet, but things aren’t working for some reason. Can you decrypt your own HTTPS traffic? The answer is yes and [rl1987] shows you how.

Don’t worry, though. This doesn’t let you snoop on anyone’s information. You need to share a key between the target browser or application and Wireshark. The method depends on the target applications like a browser writing out information about its keys. Chrome, Firefox, and other software that uses NSS/OpenSSL libraries will recognize an SSLKEYLOGFILE environment variable that will cause them to produce the correct output to a file you specify.

How you set this depends on your operating system, and that’s the bulk of the post is describing how to get the environment variable set on different operating systems. Wireshark understands the file created, so if you point it to the same file you are in business.

Of course, this also lets you creep on data the browser and plugins are sending which could be a good thing if you want to know what Google, Apple, or whoever is sending back to their home base using encrypted traffic.

Wireshark and helpers can do lots of things, even Bluetooth. If you just need to replay network data and not necessarily analyze it, you can do that, too.

ESP32 Hash Monster Fills Pockets With Packets

Unless you’re reading this from the middle of the ocean or deep in the forest, it’s a pretty safe bet there’s WiFi packets zipping all around you right now. Capturing them is just a matter of having the right hardware and software, and from there, you can get to work on cracking the key used to encrypt them. While such things can obviously have nefarious connotations, there are certainly legitimate reasons for auditing the strength of the wireless networks in the area.

It might not have the computational horsepower to crack any encryption itself, but the ESP32 M5Stack is more than up to the task of capturing WiFi packets if you install the Hash Monster firmware developed by [G4lile0]. Even if you don’t intend on taking things farther, this project makes finding WiFi access points and grabbing their packets a fascinating diversion with the addition of a few graphs and an animated character (the eponymous monster itself) that feeds on all those invisible 1s and 0s in the air.

There’s some excellent documentation floating around that shows you the start to finish process of popping open a WiFi network with the help of Hash Monster, but that’s only the beginning of what’s possible with this gadget. A quick search uncovers a number of software projects that make use of the specific advantages of the M5Stack compared to more traditional ESP32 boards, namely the built-in screen, buttons, and battery. We’ve even seen it used in a few builds here on Hackaday, such as this DIY thermal camera and custom shipboard computer system.

[Thanks to Manuel for the tip.]

Hacking D-Link Firmware

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”

Share Your Clipboard Across Machines Using MQTT

Many of us regularly move from one computer to another for work, play, and hacking; every now and then finding yourself wishing you could copy something on one machine and paste on another without additional steps in between. [Ayan Pahwa] was well acquainted with this frustration, so he created AnywhereDoor, a cross-platform clipboard sharing utility that uses MQTT.

Some cloud-based solutions already exist to do this, but that means sending your private clipboard data to someone else’s server. Not keen on that idea, [Ayan]’s solution makes use of a MQTT broker that can run anywhere on the local network, and lightweight python clients to run on Mac, Windows and Linux. The client checks your clipboard at specified intervals, and publishes new data to a topic on the broker, to which all the clients are subscribed. The data is end-to-end encrypted using Fernet symmetrical key encryption, so the data won’t be readable to anyone else on the network. Currently, AnywhereDoor only supports copying text, but media is planned for a future version.

We like the relative simplicity of the utility, and see it being very handy for hackers bouncing between machines in the lab. Simple software utilities that solve a specific and real problem can are very useful, like a wiring documentation tool, or Kicad to isolation routing patchwork converter.

Polymorphic String Encryption Gives Code Hackers Bad Conniptions

When it comes to cyber security, there’s nothing worse than storing important secret data in plaintext. With even the greenest malicious actors more than capable of loading up a hex editor or decompiler, code can quickly be compromised when proper precautions aren’t taken in the earliest stages of development. To help avoid this, encryption can be used to hide sensitive data from prying eyes. While a simple xor used to be a quick and dirty way to do this, for something really sophisticated, polymorphic encryption is a much better way to go.

A helpful tool to achieve this is StringEncrypt by [PELock]. An extension for Visual Studio Code, it’s capable of encrypting strings and data files in over 10 languages. Using polymorphic encryption techniques, the algorithm used is unique every time, along with the encryption keys themselves. This makes it far more difficult for those reverse engineering a program to decrypt important strings or data.

While the free demo is limited in scope, the price for the full version is quite reasonable, and we expect many out there could find it a useful addition to their development toolkit. We’ve discussed similar techniques before, often used to make harder-to-detect malware.

[Thanks to Dawid for the tip!]

Grey Gear: French TV Encryption, 1980s Style

Who among us didn’t spend some portion of their youth trying in vain to watch a scrambled premium cable TV channel or two? It’s a wonder we didn’t blow out our cones and rods watching those weird colors and wavy lines dance across the screen like a fever dream.

In the early days of national premium television in America, anyone who’d forked over the cash and erected a six-foot satellite dish in the backyard could tune in channels like HBO, Showtime, and the first 24-hour news network, CNN. Fed up with freeloaders, these channels banded together to encrypt their transmissions and force people to buy expensive de-scrambling boxes. On top of that, subscribers had to pay a monthly pittance to keep the de-scrambler working. Continue reading “Grey Gear: French TV Encryption, 1980s Style”