DeepSound is a steganography utility that can hide data inside of audio files. The contents can optionally be protected with a password, in which case DeepSound advertises that it encrypts using AES-256.
Used incorrectly, the security of all cryptographic algorithms, including (or perhaps especially) the beloved AES, can be devastatingly eroded. I took a peek at DeepSound to see if I could find any weaknesses in the way it performs encryption that would allow me recover the payload from a carrier file.
The first thing I noticed was that DeepSound will only prompt for a password when it is fed an audio file that actually does contain an encrypted payload. This ability to distinguish between encrypted and unencrypted payloads without first providing the password means that there is some metadata that should be easily sifted out of the carrier file. This was my first lead to investigate.
Since DeepSound is written using .NET and not obfuscated, it was possible to decompile the binary and just read the code. As a newcomer to reverse engineering C# apps, I found JetBrains dotPeek to be useful for exploring the decompiled code, and dnSpy to be a helpful debugger.
It was easy to understand from the decompiled code how DeepSound stores the header for its payload inside the audio file using a simple encoding mechanism. Remarkably, the payload remains intact after being transcoded to another format and back. After it has located this header, it checks a flag to see whether the payload is encrypted and prompts for the password if so.
To validate the entered password, DeepSound computes the SHA-1 hash of some AES key—not the password directly—and compares it to a hash stored in the header. But it isn’t obvious here where this AES key came from; if it were generated with a good password-based key derivation function, for instance, then this scheme might be reasonably secure.
It turns out that the line
this.Key = e.Key, which copies the entered password into an instance variable, does more than meets the eye:
A secure PBKDF was too much to hope for: the password is used directly as the AES key, and the SHA-1 of the password, unsalted and uniterated, is what’s written into the audio file.
From here it was easy to write a script to locate the payload in a carrier file and extract the SHA-1 hash from its header. Then it should be possible to crack the password by running a tool like John the Ripper or hashcat, or sometimes just by searching Google.
Except that I overlooked something: The
Key setter doesn’t compute the hash of the password directly; it copies it into a 32-byte buffer and computes the hash of that. In effect, it truncates or null-pads the password to a length of 32-bytes first, an idiosyncracy that precludes the use of off-the-shelf tools.
I decided to contribute support for this flavor of SHA-1 hash to John the Ripper, a tool that already knows about the imaginative password hashing schemes used by dozens of software packages. The developers of John have realized that most of these schemes are small variations on one another, whether it’s
sha1(md5(md5(password))) or what have you. Optimizing each of these algorithms by hand is too time consuming, so they have made a clever system that allows these schemes to be expressed in terms of some primitive building blocks.
For instance, DeepSound’s hashing scheme can be expressed in terms of four of these primitives: First, zero out our buffer. Then copy the password to it. Set the length of the buffer to 32, regardless of how long the password was. Lastly, compute the SHA-1 of the buffer.
Admittedly, finding the right sequence of primitives was not trivial, and there are a number of other switches to flip that I found a bit confusing. But it in the end it took only 8 lines to teach John about the new hashing scheme.
My changes have been contributed back to the John the Ripper community edition, including the
deepsound2john.py script for extracting hashes from carrier files. My thanks to Dhiru Kholia for the code review.
Unbeknown to me, DeepSound was featured in a scene of Mr. Robot, which caught the attention of Alfonso Muñoz. Alfonso has a nice write-up of his blackbox reverse engineering of the payload encoding, in which he noticed another bad flaw: the use of ECB mode for encryption. Even without the password you can see penguins.
I’ve published Thunderbolt 3 Unblocker, a macOS kernel extension that patches IOThunderboltFamily to disable peripheral compatibility checks. This permits the use of some unsupported peripherals such as the Razer Core external GPU enclosure. One vendor explained,
Apple has chosen to prevent Thunderbolt 3 devices using currently available controller chips from Texas Instruments from enumerating and functioning on the 2016 MacBook Pros. … Thunderbolt 3 peripherals [released prior to November 2016] which use this controller chip are incompatible with the new 2016 Thunderbolt 3 MacBooks.
These existing devices use Intel’s Thunderbolt 3 chipset (Alpine Ridge) in combination with the first generation of TI USB-C chipset (TPS65982). Apple requires the 2nd generation TPS65983 chipset for peripherals to be compatible.
Of course, patching your kernel to make it do unsupported things is not the safest idea, and there is likely a reason why Apple decided to disable this older chipset in the first place.
Previously, Tian Zhang’s TB3 Enabler script could be used to patch the IOThunderboltFamily binary on disk. This technique required that the script be kept in sync with macOS releases. The patch would also need to be reapplied after every system upgrade, and reverting back could be difficult. The runtime patching technique of Thunderbolt 3 Unblocker addresses all of these shortcomings.
One of the contributions of Thunderbolt 3 Unblocker is xnu_override, the small static library that does the patching in the kernel. (A few people also wrote to me to mention Lilu, a larger project with similar goals.) One nice feature of xnu_override is that it can revert all patches when you unload the kext.