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