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: Phil Weldon on 25 Jun 2006 11:27 '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 "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote in message news:1xjh5jspk94zf$.dlg(a)br.ederson.news.arcor.de... | 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!)===
From: David H. Lipman on 25 Jun 2006 13:00 From: "Phil Weldon" <notdiscosed(a)example.com> | _____ | 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
From: B. R. 'BeAr' Ederson on 25 Jun 2006 13:10 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!)===
From: Art on 25 Jun 2006 14:13 On Sun, 25 Jun 2006 17:00:45 GMT, "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote: >From: "Phil Weldon" <notdiscosed(a)example.com> > > >| _____ >| 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. 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
From: David H. Lipman on 25 Jun 2006 14:28
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 ? None of teh JPEGs which contain the malware have content worth keeping. -- Dave http://www.claymania.com/removal-trojan-adware.html http://www.ik-cs.com/got-a-virus.htm |