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 26 Jun 2006 09:17 On Mon, 26 Jun 2006 09:56:47 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote: >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. Well, BeAr, while I'm enthused about the idea, I would have to do a lot of "boning up" work before pursuing any more tests. I lack the requisite expertise and the tools in several areas. I've never even studied the various image formats in detail. Your suggestion of making sure the Saved image is lossless and non-compressed interests me though. I might give that a try just to see if the three av products still fail to alert on the result. Doing a viability test though will be difficult, I would think. I would have to allow the companion to run and then check to see if it was succussful in running the embedded code under both conditions .... unmodified JPG and modified JPG. Makes me wonder if there's a much easier way to determine that the JPG has been rendered harmless. There again, I lack the analysis tools and expertise. Art http://home.epix.net/~artnpeg
From: B. R. 'BeAr' Ederson on 26 Jun 2006 10:45 On Mon, 26 Jun 2006 13:17:42 GMT, Art wrote: > Your suggestion of making sure the Saved image is lossless and > non-compressed interests me though. I might give that a try just > to see if the three av products still fail to alert on the result. I made this suggestion for comparing equivalents of the memory imprint of different versions of a picture. It removes the necessity of direct memory access. > Doing a viability test though will be difficult, I would think. IMHO, the testbed needed is the first question, which is difficult to answer. Let's have a look a different possibilities of storing code inside a *.jpg picture: (Not all qualify as steganography, but could be efficient, nevertheless.) - Usage (abuse) of standard header fields: Would show up garbage with dedicated tools; usually unaffected by image manipulation; only few transformations to different image file formats will retain this data; can be deleted using standard tools - Creation of hidden data streams: persistence depends on algorithm for saving used by the image manipulation program; should not survive format changes - Embedding into the memory imprint of the picture: Image manipulation may or may not successfully destroy the data; changed compression factor will probably have the largest impact (as long as the visual appearance of the image shall not be altered, noticeably); code may be activated even within the other file format (that format can be compressed or not compressed, when extraction is done from memory) - Embedding in an intermediary result of decompression (for instance luminance or chrominance data or the result of a predefined step of decompression): Consequences of image manipulation and format changes aren't predictable, as long as the storage algorithm of the code is unknown; compression changes may show the best effect in destroying the code, but may be non-effective for special crafted data - Embedding into the data stream of the image *file* (on disk): Could survive image manipulation methods, as long as no compression change is involved; usually destroyed by saving with another compression factor; may survive lossless back-and-forth format changes as long as the last saving as *.jpg is done with original compression - Core information storage: the code is embedded within the data which endures the most radical image manipulation (transformation to black and white and the like): needs huge image sizes for moderate code amounts; probably combined with checksums and autocorrection; will probably survive any non-destructive image manipulation, format change,... - Specially crafted noise data with redundance for checksums and auto-correction: dto. > Makes me wonder if there's a much easier way to determine that the JPG > has been rendered harmless. This would need knowledge about the algorithm used by the malware and about the code inside the picture, IMHO. And even if the code seems defunct: If the next version of the trigger program includes some "parity" bytes, it may repair the whole thing, nevertheless. Just a few thoughts. And not meant to be complete in any way. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 26 Jun 2006 11:39 On Mon, 26 Jun 2006 16:45:34 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote: >On Mon, 26 Jun 2006 13:17:42 GMT, Art wrote: > >> Your suggestion of making sure the Saved image is lossless and >> non-compressed interests me though. I might give that a try just >> to see if the three av products still fail to alert on the result. > >I made this suggestion for comparing equivalents of the memory imprint >of different versions of a picture. It removes the necessity of direct >memory access. > >> Doing a viability test though will be difficult, I would think. > >IMHO, the testbed needed is the first question, which is difficult to >answer. Let's have a look a different possibilities of storing code >inside a *.jpg picture: (Not all qualify as steganography, but could >be efficient, nevertheless.) > >- Usage (abuse) of standard header fields: Would show up garbage with > dedicated tools; usually unaffected by image manipulation; only > few transformations to different image file formats will retain this > data; can be deleted using standard tools >- Creation of hidden data streams: persistence depends on algorithm > for saving used by the image manipulation program; should not > survive format changes >- Embedding into the memory imprint of the picture: Image manipulation > may or may not successfully destroy the data; changed compression > factor will probably have the largest impact (as long as the visual > appearance of the image shall not be altered, noticeably); code may > be activated even within the other file format (that format can be > compressed or not compressed, when extraction is done from memory) >- Embedding in an intermediary result of decompression (for instance > luminance or chrominance data or the result of a predefined step of > decompression): Consequences of image manipulation and format > changes aren't predictable, as long as the storage algorithm of the > code is unknown; compression changes may show the best effect in > destroying the code, but may be non-effective for special crafted > data >- Embedding into the data stream of the image *file* (on disk): Could > survive image manipulation methods, as long as no compression > change is involved; usually destroyed by saving with another > compression factor; may survive lossless back-and-forth format > changes as long as the last saving as *.jpg is done with original > compression >- Core information storage: the code is embedded within the data > which endures the most radical image manipulation (transformation > to black and white and the like): needs huge image sizes for > moderate code amounts; probably combined with checksums and > autocorrection; will probably survive any non-destructive image > manipulation, format change,... >- Specially crafted noise data with redundance for checksums and > auto-correction: dto. > >> Makes me wonder if there's a much easier way to determine that the JPG >> has been rendered harmless. > >This would need knowledge about the algorithm used by the malware >and about the code inside the picture, IMHO. And even if the code >seems defunct: If the next version of the trigger program includes >some "parity" bytes, it may repair the whole thing, nevertheless. > >Just a few thoughts. And not meant to be complete in any way. BTW, I haven't yet located a suitable image manipulator that will Save as lossless. I did a experiment this morning still using IrfanView and I found that simply Saving the image as JPG at 100% quality is sufficient to detroy detection by the three vendors. IOW, using IrfanView, there's no need to change brightness or anything. I was surprised at this result of checking file sizes: NT1.JPG Original 25,277 bytes NT1.JPG Saved by Irfan 1,643 bytes NT2.JPG Original 36,214 bytes NT2.JPG Saved by Irfan 1,634 bytes Maybe that info will give you a clue on the method used by the bad guys in this case of embedding the code. I'd guess that the embedded code was completely clobbered by whatever IrfanVeiw does when it Saves the JPG at 100% quality without any attempt at image manipulation by the user in any way. Art http://home.epix.net/~artnpeg
From: B. R. 'BeAr' Ederson on 26 Jun 2006 13:50 On Mon, 26 Jun 2006 15:39:13 GMT, Art wrote: > BTW, I haven't yet located a suitable image manipulator that will Save > as lossless. IrfanView writes "Windows Bitmap" as uncompressed. This way you should get an exact representation of the memory imprint of the currently opened *.jpg file. > I did a experiment this morning still using IrfanView and > I found that simply Saving the image as JPG at 100% quality is > sufficient to detroy detection by the three vendors. IOW, using > IrfanView, there's no need to change brightness or anything. I was > surprised at this result of checking file sizes: > > NT1.JPG Original 25,277 bytes > NT1.JPG Saved by Irfan 1,643 bytes > > NT2.JPG Original 36,214 bytes > NT2.JPG Saved by Irfan 1,634 bytes Interesting. Looks like the malware code is stored as "hidden data stream". (As I called it in my last posting.) You may experiment with advanced options (keep original EXIF/IPTC/Comments) to see, whether the code is located in such fields. And you may test the structure using this (or a similar) tool: www.picturel.com/utils.html (JPEGInfo) > I'd guess that the embedded code was completely clobbered by whatever > IrfanVeiw does when it Saves the JPG at 100% quality without any attempt > at image manipulation by the user in any way. Sounds reasonable. But to be sure... ;-) BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 26 Jun 2006 15:06
On Mon, 26 Jun 2006 19:50:07 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote: >On Mon, 26 Jun 2006 15:39:13 GMT, Art wrote: > >> BTW, I haven't yet located a suitable image manipulator that will Save >> as lossless. > >IrfanView writes "Windows Bitmap" as uncompressed. This way you should >get an exact representation of the memory imprint of the currently >opened *.jpg file. I just noticed there's a "lossless" plugin for Irfan which I've yet to download. >> I did a experiment this morning still using IrfanView and >> I found that simply Saving the image as JPG at 100% quality is >> sufficient to detroy detection by the three vendors. IOW, using >> IrfanView, there's no need to change brightness or anything. I was >> surprised at this result of checking file sizes: >> >> NT1.JPG Original 25,277 bytes >> NT1.JPG Saved by Irfan 1,643 bytes >> >> NT2.JPG Original 36,214 bytes >> NT2.JPG Saved by Irfan 1,634 bytes > >Interesting. Looks like the malware code is stored as "hidden data >stream". (As I called it in my last posting.) You may experiment with >advanced options (keep original EXIF/IPTC/Comments) to see, whether >the code is located in such fields. And you may test the structure >using this (or a similar) tool: I've been leaving those checked. > www.picturel.com/utils.html (JPEGInfo) Got and tried it out, thanks. >> I'd guess that the embedded code was completely clobbered by whatever >> IrfanVeiw does when it Saves the JPG at 100% quality without any attempt >> at image manipulation by the user in any way. > >Sounds reasonable. But to be sure... ;-) I did some searching for a (preferably) freeware image converter, and so far one freeware and one payware app seem to do a similar thing in that they cut the file size down to about 1.5 KB. The freeware 2JPEG is a command line converter that makes it convenient to write programs or batch programs to find all JPGs and filter out the embedded code, though I realize I'm getting ahead of myself here in saying that :) But most likely it seems that such a simple scheme will work for the particular method of embedding used in the subject JPG files. That IMO would be cool. At least it seems quite promising at this point. Art http://home.epix.net/~artnpeg |