J
James Egan
I suppose not. It would certainly help to clean up the steganography
market and "out" the plethora of crapware which claims to be
undetectable but is just a con.
Jim.
I suppose not. It would certainly help to clean up the steganography
market and "out" the plethora of crapware which claims to be
undetectable but is just a con.
Jim.
A
Art
I know, and most likely the data loss blows away one idea I had which
was was to attempt a reversal to a bitmap image which might be
analyzed for noisyness. Even then though, sig/noise ratios would be
prohibitively small with a smal number of embedded bytes. Perhaps one
reason I thought of the idea is the fidelity enhancement that's been
done on audio recordings made many decades ago, where there is analog
data loss , so to speak, yet much "data" is recreated.
So I'm stumped right now on even the reduced problem of detecting that
something is amiss and then warning users.
I hate to since I can't get past JPGs
You and most everyone else, it seems. Clearly, you and others are way
ahead of me in giving thought to the problems. It's fine that people
have brought up the more general problems and issues in this thread.
Personally, I'm still wondering about what's going on with the av
vendors concerning the subject sample files. It strikes me as very
curious that only three vendors (as of last night) alert on the JPGs
and they each have their own unique kind of alert ... Symantec going
so far as to specify three different malwares in the three different
JPGs. It's also curious that neither David Lipman nor myself have
heard a peep back from Kaspersky concerning the JPG samples. It will
be interesting to see how this unfolds.
Art
http://home.epix.net/~artnpeg
P
Phil Weldon
'B. R. 'BeAr' Ederson' wrote, in part:
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
_____
The overall 'brightness' change propagates thru the recompression, even
reusing the same compression process with the same compression factor.
There are many filters that will do the same.
My suggestion is for a simple change to an image that would destroy
executable code, not a generalized method for defeating steganography.
You describe the beginning of an arms race, which I brought up my subsequent
reply to 'Art'.
Phil Weldon
message | On Sun, 25 Jun 2006 01:25:38 GMT, Phil Weldon wrote:
|
| > Try an image editor and change the overall 'brightness by 1%. That
should
| > destroy any executable hidden in a .jpg image.
|
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
|
| If you try your suggestion on an image twice in a row to ensure the same
| compression settings, you'll find large portions of the images 2 and 3
| unchanged. Most of the data may shift position. But a trigger program
| can look for code snippets to get the offset of the malicious code. It
| doesn't need to depend on exact positions. If AV programs always used
| brightness changes to "disinfect" *.jpg files, virus writers would just
| place the code in the chrominance part of the data stream. (Luminance
| and chrominance are compressed separately in *jpg files.)
|
| Moreover, all JFIF (JPEG File Interchange Format) files comprise of
| several data blocks/streams. Besides using IPTC/EXIF metadata fields
| it may be not to hard a task to construct blocks neither visible nor
| changed by usual picture handling. That's the kind of pictures Art
| targets when he talks about heuristic detection of suspicious files.
| (If I get him right.) I, too, would be glad, if AV programs would
| issue a warning about data files containing seemingly executable
| code within text header fields or additional data streams.
|
| Btw.: There is currently some research on the topic, how data of
| pictures has to be manufactured to survive lossy transformation:
|
| http://research.binghamton.edu/faculty/fridrich/fridrich.htm
|
| Though the focus of the research of Jessica Fridrich is detecting
| the original source (camera) of a picture (and the like), it
| inevitably also shows, where to "best" hide information...
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
_____
The overall 'brightness' change propagates thru the recompression, even
reusing the same compression process with the same compression factor.
There are many filters that will do the same.
My suggestion is for a simple change to an image that would destroy
executable code, not a generalized method for defeating steganography.
You describe the beginning of an arms race, which I brought up my subsequent
reply to 'Art'.
Phil Weldon
message | On Sun, 25 Jun 2006 01:25:38 GMT, Phil Weldon wrote:
|
| > Try an image editor and change the overall 'brightness by 1%. That
should
| > destroy any executable hidden in a .jpg image.
|
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
|
| If you try your suggestion on an image twice in a row to ensure the same
| compression settings, you'll find large portions of the images 2 and 3
| unchanged. Most of the data may shift position. But a trigger program
| can look for code snippets to get the offset of the malicious code. It
| doesn't need to depend on exact positions. If AV programs always used
| brightness changes to "disinfect" *.jpg files, virus writers would just
| place the code in the chrominance part of the data stream. (Luminance
| and chrominance are compressed separately in *jpg files.)
|
| Moreover, all JFIF (JPEG File Interchange Format) files comprise of
| several data blocks/streams. Besides using IPTC/EXIF metadata fields
| it may be not to hard a task to construct blocks neither visible nor
| changed by usual picture handling. That's the kind of pictures Art
| targets when he talks about heuristic detection of suspicious files.
| (If I get him right.) I, too, would be glad, if AV programs would
| issue a warning about data files containing seemingly executable
| code within text header fields or additional data streams.
|
| Btw.: There is currently some research on the topic, how data of
| pictures has to be manufactured to survive lossy transformation:
|
| http://research.binghamton.edu/faculty/fridrich/fridrich.htm
|
| Though the focus of the research of Jessica Fridrich is detecting
| the original source (camera) of a picture (and the like), it
| inevitably also shows, where to "best" hide information...
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===
D
David H. Lipman
From: "Phil Weldon" <[email protected]>
| _____
| The overall 'brightness' change propagates thru the recompression, even
| reusing the same compression process with the same compression factor.
|
| There are many filters that will do the same.
|
| My suggestion is for a simple change to an image that would destroy
| executable code, not a generalized method for defeating steganography.
|
| You describe the beginning of an arms race, which I brought up my subsequent
| reply to 'Art'.
|
| Phil Weldon
|
Since there is NO content worth saving, manual deletion or removal via AV software is
warranted. Modification with a Graphics manipulation application is just a wasteful action.
| _____
| The overall 'brightness' change propagates thru the recompression, even
| reusing the same compression process with the same compression factor.
|
| There are many filters that will do the same.
|
| My suggestion is for a simple change to an image that would destroy
| executable code, not a generalized method for defeating steganography.
|
| You describe the beginning of an arms race, which I brought up my subsequent
| reply to 'Art'.
|
| Phil Weldon
|
Since there is NO content worth saving, manual deletion or removal via AV software is
warranted. Modification with a Graphics manipulation application is just a wasteful action.
B
B. R. 'BeAr' Ederson
I just tried to tell you that your suggested method isn't enough. You
may knew that much by yourself. But one cannot guess that from your
postings and others may think themselves safe, applying your suggestion.
I describe 2 things: There are possibilities for general (heuristic)
detection of abnormal formed data file sections. And your described
method has to be refined to really be useful. And that's not just a
matter of including the chrominance part of the data stream - because
the compression algorithm may permit the construction of data which
survives several transformations (as seems to be the case with JPEG).
I surely *don't* propagate the inclusion of detection routines for
all steganographic methods ever detected to be used for malware.
BeAr
A
Art
Not wasteful at all if something like that could be developed that
would do the job without signifcant loss of image quality. My idea
of it is as I said ... scrub all JPG images found (with user
permission). Period. That gets around the very difficult problems
inherent in attempting to detect embedded code reliably. Very
slick solution if it can be made to work well.
Art
http://home.epix.net/~artnpeg
D
David H. Lipman
From: "Art" <[email protected]>
|
| Not wasteful at all if something like that could be developed that
| would do the job without signifcant loss of image quality. My idea
| of it is as I said ... scrub all JPG images found (with user
| permission). Period. That gets around the very difficult problems
| inherent in attempting to detect embedded code reliably. Very
| slick solution if it can be made to work well.
|
| Art
| http://home.epix.net/~artnpeg
Come on. Do you really need the Frog ?
None of teh JPEGs which contain the malware have content worth keeping.
|
| Not wasteful at all if something like that could be developed that
| would do the job without signifcant loss of image quality. My idea
| of it is as I said ... scrub all JPG images found (with user
| permission). Period. That gets around the very difficult problems
| inherent in attempting to detect embedded code reliably. Very
| slick solution if it can be made to work well.
|
| Art
| http://home.epix.net/~artnpeg
Come on. Do you really need the Frog ?
None of teh JPEGs which contain the malware have content worth keeping.
P
Phil Weldon
'Dave' wrote:
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted. Modification with a Graphics manipulation application is just
a wasteful action.
_____
Ah, but to be removed, it must be detected.
Removal of an image known to have steganographic content is trivial.
Please read my second reply to 'Art' 6/25/2006 11:27 AM.
Phil Weldon
| From: "Phil Weldon" <[email protected]>
|
|
|| _____
|| The overall 'brightness' change propagates thru the recompression, even
|| reusing the same compression process with the same compression factor.
||
|| There are many filters that will do the same.
||
|| My suggestion is for a simple change to an image that would destroy
|| executable code, not a generalized method for defeating steganography.
||
|| You describe the beginning of an arms race, which I brought up my
subsequent
|| reply to 'Art'.
||
|| Phil Weldon
||
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted. Modification with a Graphics manipulation application is just
a wasteful action.
|
| --
| Dave
| http://www.claymania.com/removal-trojan-adware.html
| http://www.ik-cs.com/got-a-virus.htm
|
|
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted. Modification with a Graphics manipulation application is just
a wasteful action.
_____
Ah, but to be removed, it must be detected.
Removal of an image known to have steganographic content is trivial.
Please read my second reply to 'Art' 6/25/2006 11:27 AM.
Phil Weldon
| From: "Phil Weldon" <[email protected]>
|
|
|| _____
|| The overall 'brightness' change propagates thru the recompression, even
|| reusing the same compression process with the same compression factor.
||
|| There are many filters that will do the same.
||
|| My suggestion is for a simple change to an image that would destroy
|| executable code, not a generalized method for defeating steganography.
||
|| You describe the beginning of an arms race, which I brought up my
subsequent
|| reply to 'Art'.
||
|| Phil Weldon
||
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted. Modification with a Graphics manipulation application is just
a wasteful action.
|
| --
| Dave
| http://www.claymania.com/removal-trojan-adware.html
| http://www.ik-cs.com/got-a-virus.htm
|
|
P
Phil Weldon
'BeAr' wrote, in part:
| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.
I really don't think that is a problem. And, I'd posit, the current samples
'Art' and 'Dave' have WOULD be rendered innocuous as executable code with a
simple manipulation. But maybe not. The proof is in the pudding, and I
don't have any pudding.
| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.
That will ultimately fail.
| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections.
What's the second?
| And your described
| method has to be refined to really be useful.
Of course. That's why I suggested 'Art' 'try' raising the brightness by 1%.
The brightness change in image editing applications is done on the
decompressed image.
Why don't you experiment with your idea of steganographic content surviving
more than one compression? And report the results here? That would be a
real contribution.
How many bits must change to render a block of code unusable?
Multiple instances of the code block with CRC?
How many angels can dance on the head of a pin? On one the pin head must be
large enough to be useful for dancing and on the other you the angels must
be seen dancing.
Phil Weldon
message | On Sun, 25 Jun 2006 15:27:46 GMT, Phil Weldon wrote:
|
| > The overall 'brightness' change propagates thru the recompression, even
| > reusing the same compression process with the same compression factor.
|
| Again:
| >| If you try your suggestion on an image twice in a row to ensure the
same
| >| compression settings, you'll find large portions of the images 2 and 3
| >| unchanged. Most of the data may shift position. But a trigger program
| >| can look for code snippets to get the offset of the malicious code. It
| >| doesn't need to depend on exact positions. If AV programs always used
| >| brightness changes to "disinfect" *.jpg files, virus writers would just
| >| place the code in the chrominance part of the data stream. (Luminance
| >| and chrominance are compressed separately in *jpg files.)
|
| > My suggestion is for a simple change to an image that would destroy
| > executable code, not a generalized method for defeating steganography.
|
| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.
|
| > You describe the beginning of an arms race, which I brought up my
subsequent
| > reply to 'Art'.
|
| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections. And your described
| method has to be refined to really be useful. And that's not just a
| matter of including the chrominance part of the data stream - because
| the compression algorithm may permit the construction of data which
| survives several transformations (as seems to be the case with JPEG).
|
| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===
| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.
I really don't think that is a problem. And, I'd posit, the current samples
'Art' and 'Dave' have WOULD be rendered innocuous as executable code with a
simple manipulation. But maybe not. The proof is in the pudding, and I
don't have any pudding.
| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.
That will ultimately fail.
| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections.
What's the second?
| And your described
| method has to be refined to really be useful.
Of course. That's why I suggested 'Art' 'try' raising the brightness by 1%.
The brightness change in image editing applications is done on the
decompressed image.
Why don't you experiment with your idea of steganographic content surviving
more than one compression? And report the results here? That would be a
real contribution.
How many bits must change to render a block of code unusable?
Multiple instances of the code block with CRC?
How many angels can dance on the head of a pin? On one the pin head must be
large enough to be useful for dancing and on the other you the angels must
be seen dancing.
Phil Weldon
message | On Sun, 25 Jun 2006 15:27:46 GMT, Phil Weldon wrote:
|
| > The overall 'brightness' change propagates thru the recompression, even
| > reusing the same compression process with the same compression factor.
|
| Again:
| >| If you try your suggestion on an image twice in a row to ensure the
same
| >| compression settings, you'll find large portions of the images 2 and 3
| >| unchanged. Most of the data may shift position. But a trigger program
| >| can look for code snippets to get the offset of the malicious code. It
| >| doesn't need to depend on exact positions. If AV programs always used
| >| brightness changes to "disinfect" *.jpg files, virus writers would just
| >| place the code in the chrominance part of the data stream. (Luminance
| >| and chrominance are compressed separately in *jpg files.)
|
| > My suggestion is for a simple change to an image that would destroy
| > executable code, not a generalized method for defeating steganography.
|
| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.
|
| > You describe the beginning of an arms race, which I brought up my
subsequent
| > reply to 'Art'.
|
| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections. And your described
| method has to be refined to really be useful. And that's not just a
| matter of including the chrominance part of the data stream - because
| the compression algorithm may permit the construction of data which
| survives several transformations (as seems to be the case with JPEG).
|
| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===
E
edgewalker
GEO said:
Some dll extensioned files are very nearly identical to exes. Most are
indeed executable, but can't (as named) be executed by simply invoking
them from the gui or command line.
E
edgewalker
Steganography aside, what if the companoin used a cookie file or
other text filetype to do effectively the same thing? Do you really
want to scan all filetypes for all known encoding or compressing
algorithms?
They're going down the wrong path in alerting on these harmless files.
They will howevr achieve their ultimate goal of marketing FUD.
other text filetype to do effectively the same thing? Do you really
want to scan all filetypes for all known encoding or compressing
algorithms?
They're going down the wrong path in alerting on these harmless files.
They will howevr achieve their ultimate goal of marketing FUD.
E
edgewalker
B. R. 'BeAr' Ederson said:
What about rotating 90 degrees...or interleaving the bitmapped image
data and resaving?
....of course, all could be gotten around with newer malware versions.
K
kurt wismer
Art wrote:
[snip]
also known as lsb steganography
(http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice)
[snip]
if i'm not mistaken, the companion *extracts* the code from the jpg and
then runs it... the jpg itself is never actually run... that's how
steganography generally works anyways (the stego app extracts the hidden
information for subsequent use)...
[snip]
also known as lsb steganography
(http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice)
[snip]
if i'm not mistaken, the companion *extracts* the code from the jpg and
then runs it... the jpg itself is never actually run... that's how
steganography generally works anyways (the stego app extracts the hidden
information for subsequent use)...
K
kurt wismer
David said:
i believe the idea is to neuter all possible steganographic archives in
images without going to the trouble of locating/identifying them... in
the example in question it's easy enough to find out which image to get
rid of, but in general it may not be...
A
Art
Needing the frog has absolutely nothing to do with it, David.
So what? That's completely beside the point and irrelevant.
Art
http://home.epix.net/~artnpeg
A
Art
Nonsense. I think those who think there's no harm in not having a
means of dealing with the issue are sticking their heads in the sand.
Those damn frogs will bite you sooner or later
Art
http://home.epix.net/~artnpeg
D
David H. Lipman
From: "Art" <[email protected]>
| On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman"
| Needing the frog has absolutely nothing to do with it, David.
||
| So what? That's completely beside the point and irrelevant.
|
| Art
| http://home.epix.net/~artnpeg
I don't think so. These JPEGs are provided, not requested. Therefore just remove the
bloddy things. I see no need for graphics manipulation to deal with this. I think it to be
wasteful endeavour.
| On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman"
|| said:
| Needing the frog has absolutely nothing to do with it, David.
||
| So what? That's completely beside the point and irrelevant.
|
| Art
| http://home.epix.net/~artnpeg
I don't think so. These JPEGs are provided, not requested. Therefore just remove the
bloddy things. I see no need for graphics manipulation to deal with this. I think it to be
wasteful endeavour.
A
Art
On what basis? How do users know which JPGs are infested and which
aren't?
Art
http://home.epix.net/~artnpeg
E
edgewalker
Art said:
All they are doing is trying to draw in those that don't use AV, because they
only trade pictures (jpegs) with friends and relatives, into the marketplace.
Those damn frogs will bite you sooner or later
There is plenty of code already on everyones machine that, if used maliciously,
will destroy data. Why worry about malware that needs ini files in the form of
text or other non-executable filetypes? And who gives a hoot if it is stego or
crypto or compressed? Bottom line - the executable is the malware in this case.
D
David H. Lipman
From: "Art" <[email protected]>
|
| On what basis? How do users know which JPGs are infested and which
| aren't?
|
| Art
| http://home.epix.net/~artnpeg
You're not going to be getting JPEGs from reputable companies that have a Trojan embedded.
You'll be getting them at malicious locations. That's why detection is important. If they
are found, the file should summarily be deleted.
|
| On what basis? How do users know which JPGs are infested and which
| aren't?
|
| Art
| http://home.epix.net/~artnpeg
You're not going to be getting JPEGs from reputable companies that have a Trojan embedded.
You'll be getting them at malicious locations. That's why detection is important. If they
are found, the file should summarily be deleted.