[extropy-chat] Re: codes in scam letters

Harvey Newstrom mail at harveynewstrom.com
Tue Sep 27 23:09:03 UTC 2005


On Sep 27, 2005, at 11:13 AM, Eugen Leitl wrote:

> On Tue, Sep 27, 2005 at 10:23:49AM -0400, mail at harveynewstrom.com 
> wrote:
>
>> If done correctly, steganography can theoretically be undetectable.
>> However, in practice, it is almost never done so well.
>
> Yes, many current packages leave a detectable signature. Very few ones
> are quite difficult to detect.

Just to be clear, I am not talking about the steganography signatures 
here.  I am talking about detecting the signature of the graphics 
program used to create the image.  Knowing what program created the 
image will give us extensive parameters as to exactly what bit 
combinations could and couldn't be produced by that program.

>
>> In the real world, image programs leave signatures inside the picture 
>> data
>> so you can tell what program created the image.  Often, this is 
>> explicitly
>
> No problem, we're just after the payload data.

I think you missed my point.  I am after the exact name and version 
level of the original program that created the graphic, not the 
payload.  The payload is hard to determine.  But I am going after the 
image which is easier to predict once you know the program and 
compression algorithms used.

>> stated within a tag that gives the program name, version, date, etc.
>> Otherwise, the internal structure of the graphic can be analyzed to
>> identify the original program.  The programs also contain compression
>> signatures that indicate what level of compression and what 
>> algorithms were
>> used to reduce the image size.  Again, this is often explicitly 
>> stated in a
>> tag within the picture, or can be reverse-engineered by examining the
>> internal structure of the compression.
>
> No problem, we're just after the payload data.

Ditto my above comment.  For my method of detecting the hidden message, 
I need to identify the compression algorithm used by the image.

>> What this means is that it is trivial for a person to grab the image 
>> binary
>> off the net, load it into the indicated program, and save it with the 
>> same
>> compression level and method indicated.  This should produce the 
>> exact same
>
> This will change some bits in the headers, so I wouldn't use a 
> commercial
> program for that.

This is exactly my point.  Using the original commercial program will 
alter the headers.  It will also alter the internal structure, 
compression, color table and make all sorts of program-specific changes 
to the image.  The question is:  Do these changes match the posted 
image, indicating it really was produced by that graphics program and 
was posted unaltered?  Or, do these changes not match the posted image, 
indicating that the image is inconsistent with what should have come 
out of the graphics program had it been left unaltered?

>> binary, because all the structures, formatting and compression should
>> already be exactly as that program and compression combination would
>> produce them.  There should be no noise or randomness that has not 
>> already
>> been optimized away.  If there is any change in the image when doing 
>> this,
>
> All images from physical sensors have noise. No compression algorithm 
> is
> perfect.

True.  But they are predictable.  If we run an image through a 
particular graphics program using a particular compression program, it 
will smooth out some things, but miss others.  The exact pattern of 
what it smooths out and what it misses is predictable.  We can compare 
the posted image to what the graphics program and compression algorithm 
should produce.  If it matched, great.  But if it doesn't, we have an 
tampered graphic.

>> it indicates that the changed bits were tweaked after the original 
>> picture
>> was produced and were not a natural product of the imaging software.  
>> These
>> changed bits can then be isolated, extracted, and analyzed separately 
>> from
>> the overall image information.
>
> You don't have access to the "original" picture, however.

I don't need the original picture.  If the graphics program and 
compression algorithm used removes noise from the posted picture, I 
know this is added noise that wasn't there in the original.  If it were 
there in the original, the graphics program and compression algorithm 
would have removed it in the original.  In this case, the noise must 
have been added after the picture was originally created and 
compressed.

>> Thus, it is trivial in most cases to extract and analyze any random 
>> bits
>> introduced to the imaging after processing.  Using this method, we can
>> confirm that the vast majority of the pictures posted on the net are 
>> free
>> from hidden messages.  One would have to use a non-standard or unknown
>
> Moreover, as cryptographic hashes are used to trace files on P2P
> networks, we know that the files are not tampered with in transit.

I don't see what this has to do with my method.  My method is for 
detecting if images from strangers have secret messages in them.  In 
that case, I wouldn't have a cryptographic hash.

>> graphics format with zero or non-standard compression to produce 
>> images
>> with messages hidden in them.  Such a format could be detected as 
>> unusual.
>
> There is no need to change the headers nor produce corrupt images if
> you're hiding a few bits in a largish picture, or a few kbytes in a 
> large
> movie (4 GByte files are widespread on P2P networks).

My method does not necessarily detect changed headers or corrupted 
images.  I am talking about any added bits in the picture that would 
normally get smoothed out by the compression method but didn't.  I.E., 
they add the message after the image is compressed.  Adding it before 
wouldn't work because the message might get optimized out.  This is the 
key to my method.  I can detect optimization changes between what was 
posted and what the original graphics program and compression should 
have produced.  Bits that should have been optimized out but weren't 
obviously were added in after the optimization.  This is what I am 
detecting with this method.

--
Harvey Newstrom <HarveyNewstrom.com>
CISSP CISA CISM CIFI NSA-IAM GSEC ISSAP ISSMP ISSPCS IBMCP




More information about the extropy-chat mailing list