"not an AxCrypt file" and "invalid block type" errors

[VeryAngryUser]

I’m running the free version 2.1.1547.0 on Windows 10 64.

I always encrypt/decrypt the same groups of files by selecting them all and right-clicking, AxCrypt, Encrypt/Decrypt.

Many of my files have now been rendered indecryptable since I keep getting the “not an Axcrypt file” and some times the “Invalid Block Type” errors. I am positive I did not rename, move, or modify any of the files in any form, nor did the program crash, nor did the power fail at any moment. It seems AxCrypt simply decided to screw with my files.

On the other hand, many other files in the same folder might not be damaged but since the decryption process halts as soon as a it finds a problem with one single file it’s going to take me hours to sort through the whole group of files, one by one, checking if they still work.

This is really frustrating.

Based on other cases I’ve read here, I have the feeling you’ll say that this is “a first” and you’ll see what you can do and most likely end up telling me you’re very sorry for my loss of data, yet I still had to give it a try.

So far I’m not feeling very compelled to upgrade to premium.

[SvanteSpectator]

Hello VeryAngryUser,

First of all, I am very sorry indeed if the damage to your files is caused by AxCrypt.

Although it has nothing to with the problem at hand, I’d like to note that the workflow “right-clicking, AxCrypt, Encrypt/Decrypt” is seldom the most convenient. For applications that are document-oriented and associate with a given file type, double-clicking and letting AxCrypt handle the decrypt/encrypt operations is much easier.

You report two different errors, that may or may not be related, and may or may not be caused by AxCrypt. First some background to explain what these errors mean.

An AxCrypt-encrypted file is coded in a special way. First of all in all AxCrypt-files comes 16-bytes. Originally randomly selected, but the same for every single AxCrypt-encrypted file ever encrypted. This we call a ‘magic GUID’.
Then, follows ‘meta-data’, i.e. data about the file, in various encrypted sections. These includes the original date/time-stamps, the original file name, encrypted file sharing keys, and similar. These we call ‘headers’.
Then the encrypted data follows. At the end of the file, we duplicate these headers for redundancy and add a special keyed encrypted checksum to ensure that nothing has been modified in the encrypted data.

The first error, “…not an AxCrypt file” means that the first 16 bytes of the file are not the ‘magic GUID’ we expect. This is most often caused by user renaming of files to end with .axx, although they in fact were not encrypted by AxCrypt. Historically we occasionally had this problem with AxCrypt 1.x in combination with prematurely ejected USB-drives and in some cases, dropped network connections to file shares. We do have not had any confirmed such incidents with AxCrypt 2.x, although there’s been a very, very few reports where we’ve not been able to determine the exact cause.

The second error “Invalid block type” means that after correctly identifying the first 16 bytes, when trying to interpret the headers mentioned above, we encountered a block type with an invalid value (note that we are forward compatible with new block-types, the structure is such that we can ignore them). In this case the block type (or header type if you like) has a value that should never happen, now or in the future.

The first, when noted in version 1.x, was caused by data never actually being written to disk because of lost contact with the file system. We’ve sturdied up this in version 2.x by always writing forward, never backtracking in the file. We also added the duplicate headers at the end, as a redundancy.

The second is, as you foretold, essentially a new one. I can’t recall at least if we’ve seen that before. We have seen reports of a similar sounding problem, where the decompression layer has problems, but once again this is once or twice for the entire lifespan of AxCrypt 2.x.

What I’d like to do next, is actually see some of these damaged files. Please remember, they are purportedly encrypted and the whole purpose of AxCrypt is to ensure that if the files are seen by someone else, they can’t be decrypted. I do not want to have your password. Just damaged, encrypted, files. If you are agreeable, please contact me via support and attach the damaged files, and also a full error report as described here: https://forum.axcrypt.net/blog/send-complete-error-report/ . The purpose of the full error report is to ensure we know exactly what you are seeing, and also seeing if we can find traces of crashes or other errors in the logs included (the AxCrypt log and the Event log).

[Author]

Posts