Specifically with PNG it has a concept of "private" chunks which you can use to store arbitrary data. Conforming decoders will ignore these chunks, and may or may not drop them if the file is modified. See https://en.wikipedia.org/wiki/Portable_Network_Graphics#%22C...
This is very nitpicky, but does adding extra data at the bottom of the image count as steganography? I've always thought of steganography as something that is very hard to detect, like changing the LSB of each pixel to a part of your message.
I'd say communicating outside normal means would be "using a covert channel", and reserve "steganography" for such communication as has been whitened to resemble noise[1].
Obviously tastes may differ, so someone else might call the former "steganography" and distinguish the latter as "deniable steganography", or at least "near-noise steganography".
(with a little information theory, one can even communicate reliably via sub-noise steganography)
"... a method of expressing and signifying one's mind to any distance by objects that are either visible or audible — provided only the objects are but capable of two differences ..."
I'd say communicating outside normal means would be "using a covert channel", and reserve "steganography" for such communication which has been whitened to resemble noise[1].
Ah. I think I see where the confusion is coming from. You're saying this isn't steganography because the information isn't hidden in the image data. It's there in the 'plaintext'. I thought this is steganography because the image is hidden in the file data by exploiting the fact that PNG renderers don't display it.
I'm going to change my mind and say that your definition is actually better than mine. The information itself isn't hidden. You don't need a trick, or a key, or any special knowledge to view it. The fact that common PNG libraries don't display it isn't really enough to say that it's enciphered at all - you can't really say a message is definitely hidden if you assume something about the PNG library the attacker is using to view it. I don't know what the right term is, but it probably isn't steganography.
More "security by hoping they don't look".
And in fact, the suggested uses of overlong PNG chunks in the linked article aren't particularly secure ones.
This might be how the term steganography is mostly used these days, but I disagree that it's the definition of steganography.
An early example of steganography is writing on the scalp of a person and concealing it with the regrowth of hair: https://en.wikipedia.org/wiki/Steganography#History . The message is clear-text, you just have to know where to look for it. Which is the same as in the blog post.
If it includes a marginally hidden container with an obvious structure this sense of "steganography" seems formally correct (secrecy without a secret key) but overly broad in practice.
Consider, for example, that you can apply "normal" steganography to the image data in the overlong PNG content (claiming, for example, that you just "hid" a porn picture at the bottom of a cute kitten while there's a secret message in the whole composite picture).
It's hard for me to see how splitting hairs gets you any farther from calling it steganography when you find a place in a binary format where you can write arbitrary bytes. The covert channel is the payload handed over in broad daylight. How the secret is encoded or not is just impl detail.
There's obviously a spectrum of how hidden the message is. e.g. tacking bytes onto the end of the image blob vs encoding your message by inc/decrementing rgba values away from the original.
The former is trivial to remove in this case (can just diff images with different messages or run the image through an optimizer), the latter is impossible to remove though you can ruin the encoded message, but surely they both check the high level definitions of steganography.
> "For if a letter should come into the hands of such as have a power over the writer or receiver, though the cipher itself be trusty and impossible to decipher, it is still subject to examination and question, unless there be no room to suspect or examine it."
I doubt many slaves' heads were shorn looking for messages (and if they had been, the eavesdropping would be, as in QE, obvious), but overlong images are begging to be flagged by a linter https://news.ycombinator.com/item?id=24341108 , and anyone who naively stuffs plaintext there should hope no one ever runs strings(1).
Anyway, as mentioned above, I don't care if the general case is called steganography, I'm just curious what then the specific case (of writing that has a "cover story") would be called?
Nothing stopping you encrypting a steganographic message. Denying message existence isn't going to be possible in a system that also compresses data and leaks file size - the latter rules out having null states (all RF communication?) or large blocks of zeros (most, if not all, storage?).
You could do something to avoid that, by doing a LOT of padding with random bits - but again, that's back to encryption, isn't it? Except encryption is something you can apply in the real world, where constant broadcast is usually impractical.
Steganography is usually meant to refer to covert, deniable information encoding, while extra data is too unsubtle to be hidden from an adversary. It's a simple and convenient trick to hide data from unsuspecting users who don't look for secrets, a weaker threat model.
Actual image-based steganography schemes, as used e.g. for watermarks, usually alter pixels in a way that is approximately (and hopefully) undistinguishable from plausible noise.
The PNG format supports arbitrary data being included in private (nonstandardized) chunks, which will be ignored by decoders that don’t recognize them. It’s easier to extract and more reliably hidden, so why bother inserting the extra data as pixels?
The threat model is that of an active attacker that is able to tamper the message,- either inserting his own malicious data in the extra chunk, or zeroing it out if you are using strong authentication,- but that does care of the quality of the cover message (the image itself).
By encoding the secret message in the pixels themselves, you ensure that the attacker cannot significantly alter the secret message without degrading the quality of the image itself. One application is watermarks containing copyright notices. The idea is that the infringing party cannot render the watermark undetectable without also degrading the quality (and by proxy, the economic value) of the image they are trying to plagiarize.
Of course, that goal cannot be achieved by simply storing the secret message in the least significant bit of the image. You need to have a model of what type of tampering the attacker is going to perform, and then design an encoding that will be resistant to such attack.
PNG's IDAT chunk, which contains actual image data, is simply all lines of data compressed with the deflate algorithm. Once you inflate (uncompress) it, you have all data and can compare if width and height match. This way it is quite easy to detect if additional data was added.
Sorry if this is a dumb question, but what does hiding information in images have to do with CTF-style challenges? Does that term not refer to "break into server X and retrieve file Y" sorts of tasks?
CTF games come in two styles (attack and defense i.e. PvP, and jeopardy i.e. PvE), and within the jeopardy class there are many categories, one or which can be steganography, file formats, and related challenges.
(Source: I run a CTF, have written over 100 challenges, and the JPEG padding trick was one of them years ago)
Doesn't it store it in the low bits of visible picture?
That's what I do for my own virtual console project. While the methods listed in this article are pretty neat, once you go browser based you are limited to what the browser gives you access to. The only alternative is doing a request for the file and doing the entire file format decoding in JavaScript. If you go that far then you might as well use a zTXt or custom chunk.
I actually developed a game which used this trick for an Easter egg. I added in a texture for the Companion Cube from Portal, and set the alpha to 1. In game, however, I loaded the textures with only a single bit of alpha, which meant that the alpha of 1 was the same as 255. Not entirely invisible, but was fun to do!
I wrote something similar but for the ZIP format, called Pure, to detect hidden buffer bleeds outside and between and within structures, amongst other anomalies. It's also amazing what you can do with a ZIP file.
The goal of Pure is to reduce the attack surface available for zero-days by doing the simple yet critical buffer bounds checks that most end-user application software will not, and to do this for more and more popular file formats.
The vision is that one day you can deploy Pure at your email server and get much stronger guarantees on the safety of email attachments that you open... as well as on the attachments you send out... for example that your billing software is not leaking the contents of sensitive server memory into XLSX reports that you are mass mailing to clients (Pure actually found two cases of prominent investment firms that were doing just this).
It's like type checking or linting but for everyday file formats.
"Back in the day" there was an image board where people uploaded JPGs that actually were zip archives when you renamed the extension. People would post music albums like that where the image was the cover art.
I ran into a very annoying case of this in the wild: a USB hard drive "pre-formatted for Windows and Mac".
Specifically, the entire disk was pre-formatted as both NTFS and HFS+.
The trick: as shipped, LBA 0 contained an MBR pointing to an NTFS-formatted partition spanning the free space of an empty HFS+ volume whose (slightly larger) partition was defined by an Apple Partition Map in LBA 1.
So Windows would read the MBR and find the NTFS volume, Mac OS would read the APM and find the HFS+ volume, and all was right with the world.
Right, that is, until you plugged the disk into a Mac after writing to it in Windows, because the simple act of auto-mounting the "empty" HFS+ volume caused OS X to fill enough of the volume's "free" space to corrupt the colocated NTFS filesystem beyond repair.
You can do something similar with video too --- the width and height are padded to macroblock boundaries (usually 16 pixels) so there's plenty of space for extra data at the right and bottom.
Column padding can be done with .ico files, too. For 16 and 256 color images each line of data must be a multiple of 4 bytes. And since 16 and 256 color images are required to be included in ico images, the low color resolution does not even raise suspicion.
44 comments
[ 3.0 ms ] story [ 116 ms ] threadCould something similar be done with DEFLATE? Allocate some unused Huffman table? Put stuff in reserved bits?
"steganography" is simply the act of hiding messages, so I don't see why this wouldn't count.
What term for hiding information outside of the bounds of the image would you propose instead?
Obviously tastes may differ, so someone else might call the former "steganography" and distinguish the latter as "deniable steganography", or at least "near-noise steganography".
(with a little information theory, one can even communicate reliably via sub-noise steganography)
cryptography vs. steganography?
[1] compare Bacon (1605): https://archive.org/details/advancementofl00baco/page/256/mo...
"... a method of expressing and signifying one's mind to any distance by objects that are either visible or audible — provided only the objects are but capable of two differences ..."
Ah. I think I see where the confusion is coming from. You're saying this isn't steganography because the information isn't hidden in the image data. It's there in the 'plaintext'. I thought this is steganography because the image is hidden in the file data by exploiting the fact that PNG renderers don't display it.
I'm going to change my mind and say that your definition is actually better than mine. The information itself isn't hidden. You don't need a trick, or a key, or any special knowledge to view it. The fact that common PNG libraries don't display it isn't really enough to say that it's enciphered at all - you can't really say a message is definitely hidden if you assume something about the PNG library the attacker is using to view it. I don't know what the right term is, but it probably isn't steganography.
An early example of steganography is writing on the scalp of a person and concealing it with the regrowth of hair: https://en.wikipedia.org/wiki/Steganography#History . The message is clear-text, you just have to know where to look for it. Which is the same as in the blog post.
Some other non-computer examples: https://www.commonlounge.com/discussion/4bc16dbc2c7145ff87ad...
At the risk of "appeal to authority", my field of study is cryptography, and we used steganography in this broad sense.
tl;dr: I agree with the blog post in that it is steganography.
Consider, for example, that you can apply "normal" steganography to the image data in the overlong PNG content (claiming, for example, that you just "hid" a porn picture at the bottom of a cute kitten while there's a secret message in the whole composite picture).
There's obviously a spectrum of how hidden the message is. e.g. tacking bytes onto the end of the image blob vs encoding your message by inc/decrementing rgba values away from the original.
The former is trivial to remove in this case (can just diff images with different messages or run the image through an optimizer), the latter is impossible to remove though you can ruin the encoded message, but surely they both check the high level definitions of steganography.
https://archive.org/details/advancementofl00baco/page/254/mo...
> "For if a letter should come into the hands of such as have a power over the writer or receiver, though the cipher itself be trusty and impossible to decipher, it is still subject to examination and question, unless there be no room to suspect or examine it."
I doubt many slaves' heads were shorn looking for messages (and if they had been, the eavesdropping would be, as in QE, obvious), but overlong images are begging to be flagged by a linter https://news.ycombinator.com/item?id=24341108 , and anyone who naively stuffs plaintext there should hope no one ever runs strings(1).
Anyway, as mentioned above, I don't care if the general case is called steganography, I'm just curious what then the specific case (of writing that has a "cover story") would be called?
Nothing stopping you encrypting a steganographic message. Denying message existence isn't going to be possible in a system that also compresses data and leaks file size - the latter rules out having null states (all RF communication?) or large blocks of zeros (most, if not all, storage?).
You could do something to avoid that, by doing a LOT of padding with random bits - but again, that's back to encryption, isn't it? Except encryption is something you can apply in the real world, where constant broadcast is usually impractical.
Actual image-based steganography schemes, as used e.g. for watermarks, usually alter pixels in a way that is approximately (and hopefully) undistinguishable from plausible noise.
cf. https://en.wikipedia.org/wiki/Portable_Network_Graphics#"Chu...
Because these extra chunk are super-obvious? As soon as someone looks in your file they're going to wonder what you've added these for.
They will likely also not survive re-encoding.
The point of modern stenography is that you can't tell it's there, and it's just a part of the core image data, and that it's completely deniable.
How do you deny your nonstandard chunks?
Otherwise, you dismiss just about any examples of steganography prior to steganography on computers.
Which is fine, but as far as i know, not the commonly accepted definition.
> so why bother
The answer is - because it's more deniable. You bother because more deniable is better.
By encoding the secret message in the pixels themselves, you ensure that the attacker cannot significantly alter the secret message without degrading the quality of the image itself. One application is watermarks containing copyright notices. The idea is that the infringing party cannot render the watermark undetectable without also degrading the quality (and by proxy, the economic value) of the image they are trying to plagiarize.
Of course, that goal cannot be achieved by simply storing the secret message in the least significant bit of the image. You need to have a model of what type of tampering the attacker is going to perform, and then design an encoding that will be resistant to such attack.
(Source: I run a CTF, have written over 100 challenges, and the JPEG padding trick was one of them years ago)
That's what I do for my own virtual console project. While the methods listed in this article are pretty neat, once you go browser based you are limited to what the browser gives you access to. The only alternative is doing a request for the file and doing the entire file format decoding in JavaScript. If you go that far then you might as well use a zTXt or custom chunk.
Pure: https://github.com/ronomon/pure
The goal of Pure is to reduce the attack surface available for zero-days by doing the simple yet critical buffer bounds checks that most end-user application software will not, and to do this for more and more popular file formats.
The vision is that one day you can deploy Pure at your email server and get much stronger guarantees on the safety of email attachments that you open... as well as on the attachments you send out... for example that your billing software is not leaking the contents of sensitive server memory into XLSX reports that you are mass mailing to clients (Pure actually found two cases of prominent investment firms that were doing just this).
It's like type checking or linting but for everyday file formats.
https://media.ccc.de/v/31c3_-_5930_-_en_-_saal_6_-_201412291...
Ange Albertini shows how a file can be a multiple files in different formats at the same time. Amazing stuff.
Specifically, the entire disk was pre-formatted as both NTFS and HFS+.
The trick: as shipped, LBA 0 contained an MBR pointing to an NTFS-formatted partition spanning the free space of an empty HFS+ volume whose (slightly larger) partition was defined by an Apple Partition Map in LBA 1.
So Windows would read the MBR and find the NTFS volume, Mac OS would read the APM and find the HFS+ volume, and all was right with the world.
Right, that is, until you plugged the disk into a Mac after writing to it in Windows, because the simple act of auto-mounting the "empty" HFS+ volume caused OS X to fill enough of the volume's "free" space to corrupt the colocated NTFS filesystem beyond repair.
In the analog realm, something similar was used to add closed captioning to the video signal: https://en.wikipedia.org/wiki/EIA-608