Hashing of Graphical data
From: Acidus (acidus_at_yak.net)
Date: 03/27/04
- Next message: John Savard: "Re: Rijndael/Blowfish Cipher Question"
- Previous message: Tom St Denis: "Re: Cd-Keys and Encryption Techniques"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 27 Mar 2004 14:42:24 -0500
Folks,
I'm doing some work investigating a rather popular piece of spy
software, and could use a little advice. It uses zlib's deflate
algorithm to reduce the size of the screenshot's it takes, before
storing them unencrypted. To save more room , the program divides the
screen into 16 pieces and will only store the parts that change (like
mpeg). Further, for each screenshot piece it does need to store, the
program generates a hash from the graphical data and keeps a list of all
previous hashes I have not yet detrimined how long the sliding window is
of previous hashes, but its pretty long. When a new picture piece needs
to be written, if its hash is in the sliding window, and thus already
written to the data file, it simply writes a pointer to the previous entry.
The hash is only 32 bits. Seeing as the company used a free open
compression library, I figured this hash/checksum would be a standard as
well. However the hash doesn't seem to be CRC32, IP Checksum, Alder
Checksum. Its possible they are using a different generating polynomial,
since the only polynomials are designed for error-checking. Can anyone
give me any pointers as to what it might be? Are there any other
standard 32 bit checksums or hashes out there? How would a polynomial to
craft hashes of graphical data be different that a polynomial for
catching errors?
Thanks in advance for any info
- Next message: John Savard: "Re: Rijndael/Blowfish Cipher Question"
- Previous message: Tom St Denis: "Re: Cd-Keys and Encryption Techniques"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|