If you’ve ever read up on the basics of cryptography, you’ll be aware of steganography, the practice of hiding something inside something else. It’s a process that works with digital photographs and is the subject of an article by [Aryan Ebrahimpour]. It describes the process at a high level that’s easy to understand for non-maths-wizards. We’re sure Hackaday readers have plenty of their own ideas after reading it.
The process relies on the eye’s inability to see small changes at the LSB level to each pixel. In short, small changes in colour or brightness across an image are imperceptible to the naked eye but readable from the raw file with no problems. Thus the bits of a smaller bitmap can be placed in the LSB of each byte in a larger one, and the viewer is none the wiser.
OpenWRT is one of my absolute favorite projects, but it’s had a rough week. First off, the official OpenWRT forums is carrying a notice that one of the administrator accounts was accessed, and the userlist was downloaded by an unknown malicious actor. That list is known to include email addresses and usernames. It does not appear that password hashes were exposed, but just to be sure, a password expiration has been triggered for all users.
In a world with finite storage and an infinite need for more storage space, data compression becomes a very necessary problem. Several algorithms for data compression may be more familiar – Huffman coding, LZW compression – and some a bit more arcane.
Steganography refers to the method of concealing messages or files within another file, coming from the Greek words steganos for “covered or concealed” and graphe for “writing”. The practice has been around for ages, from writing in invisible ink to storing messages in moon cakes. The methods used range from hiding messages in images to evade censorship to hiding viruses in files to cause mayhem.
The developer explains that since every file is just a bit sequence, observing files leads to the realization that a majority of bits will be equal on the same places. Rather than storing all of the bits of a file, making modifications to the hard drive at certain locations can save storage space. What is important to avoid, however, is lossy file compression that can wreak havoc on quality during the compression stage.
The compression technique they ended up implementing is based on the F5 algorithm that embeds binary data into JPEG files to reduce total space in the memory. The compression uses libjpeg for JPEG decoding and encoding, pcre for POSIX regular expressions support, and tinydir for platform-independent filesystem traversal. One of the major modifications was to save computation resources by disabling a password-based permutative straddling that uniformly spreads data among multiple files.
One caveat – changing even one bit of the compressed file could lead to total corruption of all of the data stored, so use with caution!
Some sentences have more than meets the eye, and we’re not talking about interpretive nonsense. Rather, some sentences may contain up to four paragraphs’ worth of hidden text, invisible to readers.
Thanks to Zero Width Obfuscation, it is possible to use Zero Width Characters – Unicode characters that are invisible even when you try to highlight them. They’re typically used for abstract foreign languages that require separators that don’t take up an entire space. In this case, they’re used to obfuscate and de-obfuscate hidden messages sent through text.
[inzerosight] published a browser extension that identifies, de-obfuscates, and obfuscates these messages for you on the web. It does this by querying each page for the Unicode of the Zero Width Characters (U+FEFF, U+200C, U+200D, U+200E, U+2060, U+180E) and highlighting where they’ve been spotted. The encoding replaces each Unicode character with a permutation of two of the Zero Width Characters, essentially doing a find and replace across the text message.
I’m just waiting to see how long it takes for Zero Width Obfuscation to become the next Konami Code Easter Egg.
In a move guaranteed to send audiophiles recoiling back into their sonically pristine caves, two doctoral students at ETH Zurich have come up with an interesting way to embed information into music. What sounds crazy about this is that they’re hiding data firmly in the audible spectrum from 9.8 kHz to 10 kHz. The question is, does it actually sound crazy? Not to our ears, playback remains surprisingly ok.
You can listen to a clip with and without the data on ETH’s site and see for yourself. As a brief example, here’s twelve seconds of the audio presenting two versions of the same clip. The first riff has no data, and the second riff has the encoded data.
You can probably convince yourself that there’s a difference, but it’s negligible. Even if we use a janky bandpass filter over the 8 kHz -10 kHz range to make the differences stand out, it’s not easy to differentiate what you’re hearing:
We think of Morse code in terms of dots and dashes, but really it’s a kind of binary code. Those symbols might as well be 0s and 1s or any other pair of characters. That attribute is exactly what led to a sting operation a music lyric site called Genius.com pulled on Google. At issue was a case of song lyrics that had allegedly been stolen by the search giant.
Song lyric sites — just like Google — depend on page views to make revenue. The problem is that in a Google search the lyrics appear on the search page, so there is no longer much incentive to continue to the song lyric site. That’s free enterprise for you, right? It is, but there was a problem. It appears that Google — or, according to Google, one of their partners — was simply copying Genius.com’s lyrics. How does Genius know the song lyrics were copied? According to news reports in the Wall Street Journal and other sources, they used Morse code.
Hackers and makers see the desktop 3D printer as something close to a dream come true, a device that enables automated small-scale manufacturing for a few hundred dollars. But it’s not unreasonable to say that most of us are idealists; we see the rise of 3D printing as a positive development because we have positive intentions for the technology. But what of those who would use 3D printers to produce objects of more questionable intent?
We’ve already seen 3D printed credit card skimmers in the wild, and if you have a clear enough picture of a key its been demonstrated that you can print a functional copy. Following this logic, it’s reasonable to conclude that the forensic identification of 3D printed objects could one day become a valuable tool for law enforcement. If a printed credit card skimmer is recovered by authorities, being able to tell how and when it was printed could provide valuable clues as to who put it there.
This precise line of thinking is how the paper “PrinTracker: Fingerprinting 3D Printers using Commodity Scanners” (PDF link) came to be. This research, led by the University at Buffalo, aims to develop a system which would allow investigators to scan a 3D printed object recovered from a crime scene and identify which printer was used to produce it. The document claims that microscopic inconsistencies in the object are distinctive enough that they’re analogous to the human fingerprint.
But like many of you, I had considerable doubts about this proposal when it was recently featured here on Hackaday. Those of us who use 3D printers on a regular basis know how many variables are involved in getting consistent prints, and how introducing even the smallest change can have a huge impact on the final product. The idea that a visual inspection could make any useful identification with all of these parameters in play was exceptionally difficult to believe.
In light of my own doubts, and some of the excellent points brought up by reader comments, I thought a closer examination of the PrinTracker concept was in order. How exactly is this identification system supposed to work? How well does it adapt to the highly dynamic nature of 3D printing? But perhaps most importantly, could these techniques really be trusted in a criminal investigation?