brute force encrypted file (XOR encryption)

Question

I've got a file (GIF type if that matters) that is encrypted using the XOR algorithm. The only thing i have is the encrypted text so no key or plain text. Now i was wondering how i can brute force this file to get the (symmetrical) key to eventually decrypt it. IF i'm not mistaken it should be a 10 byte key. I've looked into using john the ripper but i almost only see that being used to brute force accounts. Also if it is relevant, i do not have a file which could contain the key so it would have to self generate it's possible keys.

update:

now i found a way to generate all possible hexadecimal keys, now i'll have to encrypt the file again with the xor algorithm to decrypt it if this makes sense. Now performing this operation is not gonna be a problem but how do i check if the encryption to decrypt worked when it had the correct key so basicly it stops trying any further?

Answer 1

You (and @gusto2) are exactly correct on using the magic number: you immediately get the first 6 bytes of the key by knowing that the first 6 bytes are GIF89a.

Following the gif specification, we can learn more of the key. Here are a few tips, where I am numbering the bytes of your file from index 0 (so bytes 0-5 correspond to the magic number):

• The last byte of a plaintext gif file is 0x3B. This possibly gives you one more byte of the key (depending on the file size, e.g. if the file size is equiv to 7, 8, or 9 modulo 10 then you get the key byte)

• After the magic number is a 7 byte Logical Screen Descriptor. The first 4 bytes tell the width and height: if you knew the width and height of your gif, then you would be able to derive the remaining 4 unknown bytes of the key. Let's assume you don't know it.

• Byte 10 of the file you will know because it corresponds to key byte 0 in your XOR encryption. When you decrypt that byte, the most significant bit is the Global Color Table Flag. If this bit is 0, then there is no Global Color Table -- which means that the next byte (byte 11) is either an image (byte is 0x2C) block or an extension (0x21) block. Again, you can decrypt this byte (because it corresponds to key byte 1) so you know exactly what it is.

• Images come in image blocks starting with 0x2C and ending with 00.

There are two approaches you can do to decrypt this:

(1) Work by hand, as I am describing it above. You should be able to interpret the blocks, and look for the expected key byte values of 0x2c, 0x21, 0x00, and 0x3b. From there you can figure out what makes sense to be next, and derive key bytes by hand; or

(2) You brute force the last 4 bytes (2^32 possible values). For each guess, you decrypt the candidate gif image and then feed the result into a gif parser (example parser ) to see if it barfs or not. If it barfs, then you know that candidate is wrong. If it does not, then you have a possible real decryption and you save it. At the end, you look through your real candidates one-by-one (you don't expect many candidates) to see which one is the right decryption.

EDIT: You said that the width and height are 640 and 960. That means that bytes 6 and 7 will be the little endian representation of 640 and then 960 in little endian for bytes 8 and 9. You should have the entire key from this. Try it and let us know if it works. Make sure you get the endianess right!