Slashdot Mirror
Blocking Steganosonic Data In Phone Calls
psyced writes "Steganography is a technique to encode secret messages in the background noise of an audio recording or photograph. There have been attempts at steganalysis in the past, but scientists at FH St. Pölten are developing strategies to block out secret data in VoIP and even GSM phone calls by preemptively modifying background noise (link is to a Google translation of the German original) on a level that stays inaudible or invisible, yet destroys any message encoded within. I wonder if this method could be applied to hiding messages in executables, too."
That's completely pointless. All it does is create an arms race. Any amount of noise you add can simply be dealt with by including the stego data more than once or using checksums or whatever. Any amount of damage sufficient to prevent any possibility of hidden messages would result in significant audible alteration of the sound to the point of unusability....
Check out my sci-fi/humor trilogy at PatriotsBooks.
The butterfly flaps its wings twice.
I repeat, the butterfly flaps its wings twice.
I wonder if we will ever have widespread end-to-end encryption for all of our private communication, so that "service providers" cannot mess with our actual message and/or data stream. I guess there will always be someone making a profit by preventing this on a legal level, sadly. When will the "mindless consumer" finally wake up and kick the government that allows all this?
I wonder if this method could be applied to hiding messages in executables, too.
Yes, a similar method has been employed by Microsoft to all the executables it ever released, ever since the times of MS-DOS.
After compilation they run the program through a special utility that modifies a few bits in the executable at random. Then they run the resulting executable through some tests and if it passes, they release it, if it crashes, they try with a different random bits.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
You can add "random noise" to an .exe file - most processors have at least some opcodes with "don't care" bits. You can alter those bits without affecting the semantics of the code.
Um, yes you can. Many instruction combinations are interchangeable. You merely need to be certain the result is same in all relevant cases for both instruction sequences. In the easy cases it might mean just to swap two instructions. See polymorphic viruses.
Additionally you can use empty areas in executable formats, in the headers or padding. Or even add an extra data segment... If file size is no issue, you can typically just concatenate some extra data in the end of file.
However, instruction sequence alteration might be the closest option in executable "steganography", because data in the headers or padding sticks out like a sore thumb.
Yes you can. Some examples: - replace "add 1024" with "substract -1024" - replace "if greater then 100" with "if greater then or equal to 99" - replace "copy a to b, copy c to d" by "copy c to d, copy a to b" Just have a look at any assembly language and use your imagination. To make matters even simpler, there are operators which completely ignore certain parameters (e.g. a JUMP operator which only takes 1 parameter leaves room for hidden data in the 2nd and 3rd operator field). There are plenty of instructions or combinations of instructions which leave room to such minor changes without any difference in execution. So for the steganographers, the goal would be to look for all of such instances in an executable, then agree on some kind of code (for example "add n" is a 1, "substract -n" is a 0). Semantically there is no difference, both codes will result in the exact same execution, but you found some wiggle room to leave a message. It was reported on Slashdot a few years ago.
scientists at FH St. Polten are developing strategies to block out secret data in VoIP and even GSM phone calls by preemptively modifying background noise
...And once again, they treat all of us like criminals for the sake of annoying (not even
preventing or catching) the 0.0001% that really pose a threat.
Good work, guys - Even a classic BOFH has higher efficacy and useability standards than anything related to the War on Non-Western, Non-Irish, Non-Russian (and "non-former-Soviet") Terror. At least the BOFH's systems work for him, you asshats can't even manage that despite taking all that daaaaaaangerous toothpaste away from us.
However, even I overstate the case here - Encoding data in background noise doesn't break any laws!
We all have every right to send hidden data, or even to use hard encryption right in plain sight. However, exercising that right may lead to some undue scrutiny, and thus we expose the real reason for techniques like this... Erosion of plausible deniability, which The Powers That Be loathe far, far more than any actual threat. It looks bad to just deport and torture someone with no evidence. But if you can demonstrate that he had (gasp!) something he didn't want the whole world to know about (because only criminals have secrets, of course), well then the sheep will approve of going all Jack Bauer on him.
Data can only be defined as varying bits of a defined pattern. So if the pattern is defined as 'a bunch of numbers that are either 0s or 1s', then the data stored within it is defined as varying the positions of 0s and 1s.
Obscuring data equals obscuring the patterns. So, to obscure the data within a 0 and 1 pattern, you might switch around the 0s and 1s.
For a message embedded in the background noise in a phone call, data may be modulated as 'loudness of background noise within a certain frequency range' or whatever. Obscuring this would be to add random data in the frequency range or whatever.
But that actually takes knowledge of the pattern used. If the pattern is rather the speaker knocking on a table, then any method designed to obscure background noise wouldn't register it or obscure it. It's similar to a scrambling technique that randomizes the 0s and 1s on a diskette sent in the post, while the actual message may be morse code holes punched in the plastic.
Conclusion: To void steganographic data, you need to know the method used to embed it.
They key to hiding data in executables is to realize that there are many instructions with multiple possible encodings.
You can also reverse the order of many comparison operations as long as you also modify the following branch/set instructions.
If you want to jam such a channel you would have to do the same job, first identifying all the possible locations for such transformations, then randomly flip half of them.
(Un?)fortunately neither the encoding nor the jamming process can be totally secure, because you can check (or know up front) which compiler had generated the original executable, then decompile/recompile and check which encodings the compiler tend to use.
Terje
"almost all programming can be viewed as an exercise in caching"
Or perturb the logic. The easy way is just to look at how polymorphic viruses did it. The hard way is to get out your disassembler and change
cmp eax, edx
jle offset
to
cmp edx, eax
jae offset
(insert your own variation here). Have a program read all cmp eax, edx (or cmp edx, eax) opcodes and output 0 for the first and 1 for the second.
I personally think this is just another government handout. There are so many much easier ways to hide a secret message than using a phone. Hell, they could just post one of those stupid lolcat pictures on the web with the message inside. The operative would only have to know something like "check all pictures of brown kittens on website X" or some such. All it takes is a single face to face meeting for the bad guy to have all the info he'll need to get orders through the web. I think they are trying to push technology as the answer when what they need is more field agents in hostile countries. But that's my 02c, YMMV.
ACs don't waste your time replying, your posts are never seen by me.
"though the parent's sig is annoying, hackneyed, stupid, redundant, and (did I already say this?) annoying."
I see the parents sig as a sort of darwinian filter on how careful one is the slashdot reader at clicking link.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
This could be better spent on more cell towers, or not allowing bastard fone companies to charge $200.00 termination fees.
Stopping secret messages? , puleeese.
"John has a long mustache"
"The chair is against the wall"
Stop that!
* Carthago Delenda Est *
I'm sure someone will correct me if I have missed something, but it seems to me that the desire by some to hide irremovable watermarks within digital streams is a similar technical challenge to adding steganographic content. Similarly, those attempting to destroy watermarks will face the same problems as those wishing to remove or destroy steganographic content.
The interesting thing is who is on which side of the battle.
Generally it's corporations who like the idea of watermarks, and individuals who don't. Individuals do however like steganography, but the authorities don't. It will be interesting to see who develops what technologies and who, if anyone, wins this arms race.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
It's along the lines of "How do you tell if there are stego images on someone's computer?"
Answer:You find the stego converter tool on their harddrive.
I want end-to-end encryption on all my calls. This could be added to cell phones with some modest changes. Not having it on VOIP is just inexcusable. If the FBI wants to tap my phone, why don't they get off their lazy asses, obtain a warrant, and do some actual work, rather than expecting everything to be handed to them on a silver platter, complete with booze and hookers. I'm under no obligation to make it easy for them.
Mea navis aericumbens anguillis abundat
Your problem is not interception of the radio signals, your problem is the (US) federally mandated CALEA interface on every switch in the network.
A mobile-to-mobile call almost always (unless you're both on the same tower) needs to pass over a landline, and to do that, it needs to be unencrypted.
That said, it is relatively easy to disrupt stego by lossy compression/decompression or vice-versa if the source is compressed. Low-order bits will get stripped in JPEGs & MP3s. This obviously doesn't work for loss-less compression as is needed for binaries. If hash or other non-compressibles found, just rehash. Once you've decided to meddle inthe datastream, some eggs will get broken. You'll have both alpha and beta errors (misses and false postives).
If you could detect and modify the background noise, then you could simply eliminate it. But I don't think that is possible, since what makes something "background noise" is the fact that it can't really be removed without damaging the foreground signal. If it could, you would have a perfect signal-to-noise ratio. Such a technology could be used to improve the bandwidth, compression ratios, etc. - which is something far more useful than fearmongering.
Unfortunately, I don't real have anything to go on other than a Google translated abstract, a Slashdot headline, and armchair knowledge of electronics. Anyone care to correct me?