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: Art on 25 Jun 2006 18:32 On Sun, 25 Jun 2006 21:55:24 GMT, "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote: >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. On what basis? How do users know which JPGs are infested and which aren't? Art http://home.epix.net/~artnpeg
From: edgewalker on 25 Jun 2006 18:39 "Art" <null(a)zilch.com> wrote in message news:r71u92dm1pad76gfilp2ruukh9gp3e4svn(a)4ax.com... > 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. 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.
From: B. R. 'BeAr' Ederson on 25 Jun 2006 18:46 On Sun, 25 Jun 2006 19:33:36 GMT, Phil Weldon wrote: >| 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. That's the second. (And maybe the method isn't worth the effort of refining, at all...) > 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. You don't get! I posted the results: The first picture I choose to manipulate the way you suggested had barely half the data altered, if you don't do a byte-by-byte comparison but allow realignment. The streams of unaltered data comprise of several dozen to several hundred bytes in a row. Enough to store code within. You can try by yourself. But it isn't worth to further pursue this in such a trivial approach. And I posted before, that outcome is supposed by design of the JPEG compression algorithm. I could sit down and think of a method to alter chrominance, too, using a method which doesn't render the picture ugly/useless. If you read (and understood) my first posting, you'd know by now, that I regard the true and sustainable "disinfection" a non-trivial task. Otherwise, similar topics wouldn't be military funded university research themes. Whether this degree of knowledge is required for dealing with that topic depends (of course) on the sophistication used by manufacturing the malicious sample. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: David H. Lipman on 25 Jun 2006 18:46 From: "Art" <null(a)zilch.com> | | 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. -- Dave http://www.claymania.com/removal-trojan-adware.html http://www.ik-cs.com/got-a-virus.htm
From: Art on 25 Jun 2006 18:56
On Sun, 25 Jun 2006 22:46:43 GMT, "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote: >From: "Art" <null(a)zilch.com> > > >| >| 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. But detection of embedded malware is highly problematical and almost non-existent at the present time. That's why I like the idea of routinely scrubbing all JPGs. Art http://home.epix.net/~artnpeg |