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 14:48 '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 "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message news:1jzng.8047$Wl.3287(a)trnddc01... | 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: Phil Weldon on 25 Jun 2006 15:33 '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 "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote in message news:1qqcdougljy79.dlg(a)br.ederson.news.arcor.de... | 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: edgewalker on 25 Jun 2006 16:47 "GEO" <Me(a)home.here> wrote in message news:449c5965.382717(a)news.telus.net... > On Fri, 23 Jun 2006 21:19:31 GMT, "David H. Lipman" > <DLipman~nospam~@Verizon.Net> wrote: > > >| I'm puzzled that only two products alert on the JPEGS > >| even though many alert on the (apparently) > >| companion malware. I would think it important to > >| alert on the JPEGS as a warning to users to get rid > >| of them. > > > >Now on another batch... > > > >Symantec is calling the submitted JPEGs -- Trojan.Frogexer!gen. > > > > The latest version of Bagle was formed by two files inside the ZIP > file, one an EXE and one a DLL. Looking at the DLL with Notepad I > noticed that it was nothing but ASCII characters: > 'ucrjsyfzimaepnc.....' 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.
From: edgewalker on 25 Jun 2006 16:59 "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.
From: edgewalker on 25 Jun 2006 17:15
"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. What about rotating 90 degrees...or interleaving the bitmapped image data and resaving? ....of course, all could be gotten around with newer malware versions. |