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: Virus Guy on 1 Jul 2006 11:24 If a JPG file that was flagged by JPG-SCAN.ZIP was really some sort of malware, would it (could it) still contain a viewable image that could be rendered by any typical viewer without resulting in any strange behavior, error messages, etc? I ran JPG-SCAN and found that it flags some legit files (such as contained in C:\Program Files\Canon\PhotoStitch\Samples). Of 50-odd files that it flagged for me, all of them open with Corel Photo-Paint - but a few are dammaged images (some part of the image is either washed out or missing).
From: Art on 1 Jul 2006 12:11 On Sat, 01 Jul 2006 11:24:02 -0400, Virus Guy <Virus(a)Guy.com> wrote: >If a JPG file that was flagged by JPG-SCAN.ZIP was really some sort of >malware, would it (could it) still contain a viewable image that could >be rendered by any typical viewer without resulting in any strange >behavior, error messages, etc? Yes, of course, the Trojanized samples I have (JPG of a little cartoon frog) all look fine in a viewer. >I ran JPG-SCAN and found that it flags some legit files (such as >contained in C:\Program Files\Canon\PhotoStitch\Samples). I mentioned that I found 10 JPGs on my PC with appendages and thus don't meet the proper JPG format. They all look fine in a viewer. >Of 50-odd files that it flagged for me, all of them open with Corel >Photo-Paint - but a few are dammaged images (some part of the image is >either washed out or missing). Currently, my scanner uses a very simple criteria for calling a JPG file suspicious. If there isn't a hex FF D9 at the end of the file but there is a FF D8 at the start, it flags it. That's all that's necessary for flagging the Trojanized samples I have. You see, the Trojanized samples have the "end of jpg" FF D9 earlier in the file. Now, chances are that the 50 files the scanner flagged for you have a FF D9 somewhere in the file with appendages after that ... just like the Trojanized samples I have. Your files have apparently gotten corrupted somehow just as the 10 files I have are corrupted. You can easily verify this using the search feature of a hex editor. Take some of those 50 files and do a search for FF D9. Again, chances are you'll find at least one occurrance but not located at the two bytes of the file. I suspect that if a FF D9 doesn't exist at all, that a viewer will complain of file corruption and not attempt to render a image. Art http://home.epix.net/~artnpeg
From: B. R. 'BeAr' Ederson on 1 Jul 2006 13:31 On Sat, 01 Jul 2006 10:21:40 GMT, Art wrote: > But now that you bring it up, I think I will include a option to truncate > the files as a convenience to users, since that would eliminate the need > to use Irfan (or other apps). So far as I can determine, the scanner > would only have to find the first occurance of the "end of JPG" marker > bytes and truncate all bytes after that. No. JFIF containers can have nested data streams. Often your method would truncate right after a preview picture, deleting the whole real thing. There can be other stream nestings, too. So the only possible way is to evaluate one JFIF block after another, parsing any data stream until EOI and continue the scan through the next JFIF blocks and data streams. You'd need to detect invalid or suspicious blocks or data to act properly. JFIF blocks have size definitions (usually at byte 2 with length word), while data streams have no size property. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 1 Jul 2006 15:02 On Sat, 1 Jul 2006 19:31:26 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote: >On Sat, 01 Jul 2006 10:21:40 GMT, Art wrote: > >> But now that you bring it up, I think I will include a option to truncate >> the files as a convenience to users, since that would eliminate the need >> to use Irfan (or other apps). So far as I can determine, the scanner >> would only have to find the first occurance of the "end of JPG" marker >> bytes and truncate all bytes after that. > >No. JFIF containers can have nested data streams. What file extension(s) is/are used? >Often your method >would truncate right after a preview picture, deleting the whole >real thing. There can be other stream nestings, too. So the only >possible way is to evaluate one JFIF block after another, parsing >any data stream until EOI and continue the scan through the next >JFIF blocks and data streams. You'd need to detect invalid or >suspicious blocks or data to act properly. > >JFIF blocks have size definitions (usually at byte 2 with length >word), while data streams have no size property. Yes, well it's no surprise that the plot thickens :) BTW, I added a search for FF D9 anywhere in the file, and two of the ten suspicious but probably legit JPGs were isolated with this test. I verified using a hex editor that they indeed had no FF D9 anywhere in the file. My guess that such files would cause Irfan to just flag them as corrupted was wrong. Irfan displays them with no complaints. I went ahead and used Irfan Save on all ten files, and they no longer flag as suspicious, meaning that they now all have FF D9 as the last two bytes in the file (as expected). Art http://home.epix.net/~artnpeg
From: B. R. 'BeAr' Ederson on 1 Jul 2006 19:27
On Sat, 01 Jul 2006 19:02:42 GMT, Art wrote: >>No. JFIF containers can have nested data streams. > > What file extension(s) is/are used? Huh? Usually, *.jpg or *.jpeg. JPEG is a compression scheme. And JFIF (JPEG File Interchange Format) is the file format mainly used to write JPEG data. An extended ISO variant is SPIFF, which supports "directories" inside the file. Still, you'll encounter such files as *.jpg/*.jpeg. As I understand the format description, your seemingly valid *.jpg which don't end with EOI might be totally valid SPIFF files with indirect data on end. That's data from too large directory entries mapped to the end of the file. IrfanView may just reorganize the files such, that the need of these extra entries disappears. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)=== |