Your next step should be to try all of the standard techniques for breaking substitution ciphers or ECB mode. You basically have a substitution cipher, where the alphabet is a 64-bit block (each 64-bit block plays the role of a single "letter"/"character"). Another way to think of it is that it sounds like the file was encrypted with ECB mode, so you could try standard techniques for cryptanalysis of ECB mode.
Basically, you start with frequency analysis. You look for repeated 64-bit blocks in the ciphertext. For each 64-bit block that appears anywhere in the ciphertext, you count its frequency (how many times it appears). You start with the most common such blocks, and look at their corresponding plaintext. Then you can look for patterns in a few of those examples. For example, does it look like the ciphertext block was obtained by xor-ing the plaintext block with a 8-byte key? Also, if you can find a few similar plaintext blocks (e.g., where they differ by just one bit or just a few bits) where you know the corresponding ciphertext blocks, stare at them and see if you can spot any patterns.
If you don't find any patterns, and you have enough known plaintext, you might try to build a dictionary. If you don't find any patterns, and you don't have known plaintext, you might try to use frequency analysis to see if you can identify repeated patterns in the ciphertext and guess what they might refer to. If you know something about the structure of the plaintext (e.g., digraph statistics), you may be able to use that to make some progress even in the absence of known plaintext. But by far your best bet is to try to hope you spot some patterns in a few known plaintext-ciphertext blocks.
Another approach might be to try to reverse-engineer the software/firmware that does the encryption/decryption (e.g., by disassembling it and figuring out how it does the encryption/decryption operation). I don't know if that will be feasible in your case.
If none of these work, you might be screwed.