4
$\begingroup$

I am assuming there is a very simple way of working this out by brute force, but I am not sure if there is a better way.

I have a file of data that I wish to get (my data, generated by a machine). This file is encrypted by some method that I have no details of (and the company has folded). However, as well as the encrypted file I have an unencrypted file by the same machine for a different date range. Looking at the file it is easy to see that the encryption is in blocks of 8 bytes, as most of the header is zeros, so where the new file says 00 00 00 00 00 00 00 00 the old file says B5 B4 24 EF 45 BC 68 C5.

So I know what 8 0s are like, and 8 ffs and a few other items. I also know it is a block as a an area that is 7 0s and one digit is completely different.

Do I just assume it is RSA or something and make a brute force on the password?

enter image description here

|improve this question|||||
$\endgroup$
  • $\begingroup$ Take a look at this and this $\endgroup$ – rath Jul 7 '13 at 17:20
  • 1
    $\begingroup$ With the information you are giving, it is hard to give a definitive answer. It is very unlikely that this is RSA. From your description a 64-bit block cipher in ECB mode seem quite probable. If you are lucky enough, it might be DES in ECB mode. Also, if you have access to the code of the program that perform the encryption, you could reverse engineer the code and check for the presence of a standard algorithm. $\endgroup$ – minar Jul 7 '13 at 18:38
  • $\begingroup$ The application is actually in hardware, it is a zeo bedside sleep machine. I don't know the hardware though I would assume it is a linux machine. A firmware update made it write unencrypted, but before that it did this 8 byte block encryption in the file. The company has folded so I see no way of accessing this information apart from taking the machine apart, and with no possibility of replacing the machine, I am not so keen to do that. $\endgroup$ – Woodinblack Jul 7 '13 at 21:17
  • $\begingroup$ Have you tried looking at this: zeodecoderview.sourceforge.net $\endgroup$ – minar Jul 8 '13 at 16:28
  • $\begingroup$ Yes, thanks, that works fine when you have unencrypted data (although not that link, zeo removed it all), but not if your data is still encrypted. $\endgroup$ – Woodinblack Jul 8 '13 at 18:37
3
$\begingroup$

No, don't assume it is RSA as it likely isn't based on the information.

You already have a possible block length. 64 bit block length could mean DES (or one of its variants such as 3DES) or blowfish. Another possibilty is that there was an 8 byte pad used in repeated XOR fashion. I'm sure there are other possible block ciphers with 8 byte block size.

Next I would look for repeated blocks. Anywhere in the plaintext file where the data is the same, see if the ciphertext data is the same. This would suggest either repeated XOR or ECB mode. If this is not the case, other modes (CBC, etc) are likely. The absence of repeated cipher blocks (where there are duplicate plaintext blocks) would seem to eliminate repeated XOR.

If that is all the information you have, your next step would be to brute force. If repeated XOR is a possibility, and since you know the header is 00 00 ..., the ciphertext would be your XOR pad. So try that and see if the decrypted file looks as you would expect.

Otherwise, I'd start with DES as it is probably the more popular of the two ciphers.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ Yes, the cipher text is always the same, so in the original, the blocks that are 00 00 00 00 00 00 00 00 always translate to the value I gave above, and as the header is largely empty, there are whole sections of repeated B5 B4 24 EF 45 BC 68 C5. There are also sections of all ffs too, which repeat. The reason for assuming it is not XOR is for those blocks that are 7 bytes of 0s and 1 byte of data (normally 1 or 2), the value is completely different in all 8 bytes. I am currently running a des bruteforce in slowtime. $\endgroup$ – Woodinblack Jul 15 '13 at 10:25
  • $\begingroup$ @Woodinblack You can try DES, but if it is two or three key triple DES then you may have to run that test into eternity... $\endgroup$ – Maarten Bodewes♦ Jul 16 '13 at 9:14
  • $\begingroup$ I am running a des, I hope it is that as although I am in no tearing hurry, eternity was longer than I was hoping to take $\endgroup$ – Woodinblack Jul 16 '13 at 16:25
  • $\begingroup$ Turns out eternity is quite a long time, so gave up, but noticed the post about the decoder today. I forgot to mark one as the answer, and although the other post helps me more, your answer correctly answers the question $\endgroup$ – Woodinblack Jan 28 '14 at 16:11
1
$\begingroup$

I'm a user of Zeo too, and had the same problem with an encrypted data file. I found this question, but it appears to be unanswered.

So I took another obvious path of social engineering instead. Searched around and did blind contact with some of the former members of Zeo to see if I could talk them into releasing the encryption.

That was successful, due to the incredible support of the previous zeo employees (who prefer to remain nameless, but thanks!)

The answer to this encryption is that they are using the soviet GOST hash function.

If anyone needs to decrypt their file, please see the link:

https://forum.quantifiedself.com/thread-zeo-shutting-down-export-your-data?pid=4171#pid4171

That jar file includes the Gost function in Java.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ Thanks very much for doing that, seems the social approach always beats the technical! Is the source of that around anywhere? $\endgroup$ – Woodinblack Jan 28 '14 at 16:12
0
$\begingroup$

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.

|improve this answer|||||
$\endgroup$
-1
$\begingroup$

The 0s suggest counter mode. I'd guess AES for no particular reason other than it's popular. If that's the case, you won't be able to the brute force the key.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ With 8 bytes blocks (64 bits), AES is unlikely. $\endgroup$ – minar Jul 12 '13 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.