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 22:13 'Art' wrote, in part: | BTW, Phil, I did try a experiment altering the brightness slightly | and it did result in all three vendors that normally alert then not | alerting. Thanks for the reply Art. Since I don't have a sample image, I can't try it myself. Applications like 'Photo Paint' in the Corel Draw suite and Adobe PhotoShop offer a lot more choices, including customized plug-in filters. Phil Weldon "Art" <null(a)zilch.com> wrote in message news:suau925k894nke3getj77e3em2bmaprgko(a)4ax.com... | On Mon, 26 Jun 2006 00:12:26 GMT, "Phil Weldon" | <notdiscosed(a)example.com> wrote: | | BTW, Phil, I did try a experiment altering the brightness slightly | and it did result in all three vendors that normally alert then not | alerting. I use IrfanView which might not be the best for the | purpose since when I Save the altered image it has a "Save | qaulity" slider which ranges from 0 to 100%. I'm concerned | that even with a 100% setting, there may be changes to | the original in addition to just brightness. Also, with just a simple | small cartoonish image as the Frog, any subjective judgements | as to discernable differences to my eye and brain betweeen | the original and the altered image are worthless in this case. | You can really make pretty drastic changes to brightness, | colors, contrast and gamma correction without noticeable | changes in to the eye in this particular case, or at least to | the subjective picture quality. | | Loss of detection by av is one thing, and viability is another | matter. The proof of the pudding, as always, is whether or | not the embedded code has been rendered unworkable and | harmless. But it's pointless for me to try viability tests on a | goat machine without knowing _exactly_ how the image is | modified. I think for that, I would need far better tools and | preparation than I have. | | I thought though that you might be interested in the result | of a sort of "quick and dirty" test anyway. I still think you have | a good idea ... at least until proven otherwise. I also think | quite a extensive develpment and testing project is required to | determine whether or not the idea is truly feasible. | | Art | http://home.epix.net/~artnpeg
From: 4Q on 25 Jun 2006 22:22 Dustin Cook wrote: > 4Q wrote: > > > Raidy an exception to the rule maybe Minders .bmp IRC worm > > His code was contained inside the .bmp file and looked like > > a little bit of random noise inside a viewer, however his > > worm was also a weak SE trick and the picture contained a > > message asking the user to rename the .bmp to a .com > > Then it operated as a normal wormoid. > > How exactly is this a good example tho? The user had to rename it to > get it to execute. :) It's a good example of an exception to the companion stego executer. i.e. the data is pseudo hidden in the picture, *but* the .bmp picture data is also a complete working program. > Art is suggesting the jpegs themselves should be detected and removed, > because they pose a danger. I maintain that without win32.exe, they are > harmless. > > I've acquired a sample of them, and I'm not sure if I will add them to > bughunter or not... I'm really not keen on the idea of scanning > jpegs... *shrug* I was talking about a .bmp that allows for machine code to be inserted into its internal structure, .bmp and .jpg don't have the same internals. (this kind of trick was used in notepad.exe as well, but was never published ;]]) Anyhow that being the case I guess you aren't going to be impressed with this next little trick a mutual hacker friend of ours showed me many years ago... How about a .vbs application that changes itself into a .com application *sound of fanfare* without any modification to the code?!? Yes a schizophrenic poly-morph application that flips from .vbs to .com then ..com to .vbs etc etc just by double clicking on it. *clue time* The trick has a vague similarity to the stego .bmp (if anyone can work it out without me having to print the code here) and involves machine code for 'decimal adjust AL after addition' </end of hax0r tricks> > > Bit lame as an ITW example but hey nice example of a hax0r > > thinking outside the box. > > It's a very sad state if his ITW thing went anyplace. Yeah it would never ever get ITW in a month of sundays but is just an example of how a coder can think beyond the limits of what systems were originally intended to do. Like when you contacted the author of ASIC and said "Hey great news, I've used your ASIC tool for virus! bet you never thought anyone would do that" *impressed?!* *grin* 4Q
From: B. R. 'BeAr' Ederson on 26 Jun 2006 03:00 On Mon, 26 Jun 2006 00:12:26 GMT, Phil Weldon wrote: ---------- restored snipped text -------------------------- >>>> 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...) > > So much for a fruitful discussion. I don't think, whether it is wise to answer, at all. But I'd like to assure you, that you still walk another path in this discussion as I do. The sentence in parenthesis doesn't mean that I consider your approach wrong. Quite the opposite. It just says, that it *may* prove unusable. And to sort that out isn't a task for *testing* a couple of images, but for *research*. > What I don't get is why you are claiming the non-existent. > > Did you post >> 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. > steganographically? My first post on that subject: Msg-ID: <1xjh5jspk94zf$.dlg(a)br.ederson.news.arcor.de> is already based on testing images and clearly states: | 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. After that, I explained the most likely reason. - Without going into the depth, because I still think the more subtle details have to be sorted out by specialists. Cryptography, steganography and compression can't be dealt with in an amateur fashion. OTOH, showing that an approach is *not* sufficient only needs one sample out of the line. And that's, what I posted about. > And I don't get why you treat a suggestion for an experiment as an excuse > for a polemic. No polemic on my side. Did your try your suggestion yourself? Under the additional condition of unchanging compression method and strength? (Which is necessary to rule out other influences when testing the effect of brightness changes.) BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: B. R. 'BeAr' Ederson on 26 Jun 2006 03:36 On Mon, 26 Jun 2006 01:12:26 GMT, Art wrote: > I'm concerned that even with a 100% setting, there may be changes to the > original in addition to just brightness. Huh? If the former compression wasn't 100%, too, the images will have *significantly* other data streams. Just save an *unchanged* image with 100% to test. The JPEG algorithm changes quantisation step width and the like according to the compression factor. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: B. R. 'BeAr' Ederson on 26 Jun 2006 03:56
On Mon, 26 Jun 2006 09:36:31 +0200, B. R. 'BeAr' Ederson wrote: > On Mon, 26 Jun 2006 01:12:26 GMT, Art wrote: > >> I'm concerned that even with a 100% setting, there may be changes to the >> original in addition to just brightness. > > Huh? If the former compression wasn't 100%, too, the images will have > *significantly* other data streams. Just save an *unchanged* image > with 100% to test. The JPEG algorithm changes quantisation step > width and the like according to the compression factor. To try this, save the original image and the one compressed afterwards with 100% into a lossless, non-compressing image format. Remind: The JPEG format is lossy even at 100%. Only JPEG2000 introduces lossless compression. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)=== |