Forum Home
Press F1
Thread ID: 124388	2012-04-24 00:00:00	Single checksum for multiple file. Possible?	CCF (6760)	Press F1

Post ID	Timestamp	Content	User
1271551	2012-04-24 00:00:00	Hi there guys Just want to hear some suggestion on this idea/problem . Working on a project that requires me to decode how a checksum value is being generated . Im not trying to reverse engineer the checksum value itself, I have the source file and the outputfile . Just wanting to figure out what items or factors may be involved in generating this checksum value . At this stage, I have the 3 images and a txt file (containing the order of the images), when these 3 images+txt file are placed into this process, a single checksum is generated . Below are the findings: 1 . The single output checksum value is not in hex form like MD5, but in decimal forms, like 6468431 . (16byte binary conversion?) 2 . If the txt file is modified, in such that the order of the images are shifted from position 1 to 2, and position 3 is swapped with position 1 etc, the checksum will come out the same . (even though any hash method will suggest otherwise) 3 . If the image file name is changed both on the image itself, and the image name in the txt file, the checksum comes out differently . (changing the filename of the image should not have altered the checksum/integrity of the images) Thus I am lost in what factors are involved in this checksum generator . Any suggestions?	CCF (6760)
1271552	2012-04-24 01:53:00	Weird. Maybe the process alphabetically sorts the files? What form is the "package" you are checksumming? An archive, or do you just feed it the names (in which case the text file seems a bit redundant)? A CRC-32 might be expressed as decimal easily enough, as opposed to MD5/SHA - what range of values do you get for different combinations? The example you gave fits into 24 bits, which may be significant.	MushHead (10626)
1271553	2012-04-24 03:19:00	Yeah =S The way the items are passed is simply by dropping/dumping the folder into the process . The dumped folder will consist of the images and the text file, no compression/zip or modified files, just ordinary jpg and txt . The output will simply be the same jpgs (same MD5 & SHA-1 hash) and txt, except the txt file will now contain a checksum setting with the checksum value in it . The checksum values (from other input files) are currently ranging from 10,000 - 2,000,000 . I would suspect the checksum does not factor in the actual txt file, as it is the file that it is a file that it will be modifying? As for the example I'd provided above, sadly that was just a random set of numbers I punched in >< . As for CRC32 into decimal, oddly that is one thing I have not tried . Though may I ask how I can go about doing it? Example of actual checksum: 96413 20534 169207	CCF (6760)
1271554	2012-04-24 04:46:00	Doesn't look like a standard checksum, unfortunately; you'd expect CRC-32 to usually give you much bigger numbers than the examples you've given - up to 232, or just over 4 billion. Obviously, larger checksums have less likelihood of collisions - the examples you gave indicate that the algorithm isn't particularly flash (read:secure), but I'd guess it would have been done as a quick & dirty sanity check to test for small changes, rather than a spy- or hacker-class method. It may be something ranging from a simple sum of all of the bytes of the files (plus their filenames, since they seem significant), to anything else the programmer thought up... If it is anything really trivial like my guess, you could try making a small change to the names & see if it makes a correspondingly small change in the checksum value. That might give you some hints.	MushHead (10626)
1271555	2012-04-24 07:38:00	Yeah, I'd investigate changing the LAST letter of the name of the last file passed. I'd start with the extension, change it from .jpg to .jph (the next letter) and see if the checksum goes up by 1, or up by some other possible multiple of 1. Repeat with .jpi and see if the increment can be deduced. If not, start on the last letter before the .jpg and repeat the process. Then on the first letter of the filename if the last letters revealled nothing, or experiment with very short filenames like "a", "b", "c".	Paul.Cov (425)
1