A Steganography sample malware
in [Anti-Virus]
|
Prev: c:\recycler\S-1-5-21-129_ ... Dc775.zip
Next: explorer.exe startet nicht richtig - HILFE bitte!!
From: kurt wismer on 25 Jun 2006 17:40 Art wrote: [snip] > I don't know what you mean by "least significant bit method". If we > can stick with the subject JPGs for the time being, clearly the > malware isn't hidden at all. also known as lsb steganography (http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice) [snip] >> Then it's not the jpg which gets executed. It's the "unknown" >> companion which just slipped past your av scanner. > > Huh? They both execute. The companion causes the code in the > JPG to run. 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)... -- "it's not the right time to be sober now the idiots have taken over spreading like a social cancer, is there an answer?"
From: kurt wismer on 25 Jun 2006 17:47 David H. Lipman wrote: > From: "Phil Weldon" <notdiscosed(a)example.com> [snip] > | 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. 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... -- "it's not the right time to be sober now the idiots have taken over spreading like a social cancer, is there an answer?"
From: Art on 25 Jun 2006 17:48 On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote: >From: "Art" <null(a)zilch.com> > > >| >| 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 ? Needing the frog has absolutely nothing to do with it, David. >None of teh JPEGs which contain the malware have content worth keeping. So what? That's completely beside the point and irrelevant. Art http://home.epix.net/~artnpeg
From: Art on 25 Jun 2006 17:52 On Sun, 25 Jun 2006 16:59:54 -0400, "edgewalker" <null(a)null.invalid> wrote: > >"Art" <null(a)zilch.com> wrote in message news:i35q921rggn37qfbt3lcdluc29ktvb5tdm(a)4ax.com... > >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 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
From: David H. Lipman on 25 Jun 2006 17:55
From: "Art" <null(a)zilch.com> | On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman" | <DLipman~nospam~@Verizon.Net> wrote: | >> From: "Art" <null(a)zilch.com> >> >|> 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 ? | | Needing the frog has absolutely nothing to do with it, David. | >> None of teh JPEGs which contain the malware have content worth keeping. | | 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. -- Dave http://www.claymania.com/removal-trojan-adware.html http://www.ik-cs.com/got-a-virus.htm |