Checking the AES code, there is padding and some manipulation with markers. This is not good. One should be able to take their .aes backup and run it through aesutil via 'aes -d -o backup.mysql.gz -f backup.mysql.gz.aes' to decrypt their backup. Currently, this is not possible.


ronan’s picture

Project: Backup and Migrate » AES encryption
Version: 7.x-2.2 » 7.x-1.x-dev

Encryption is handled by the AES Encryption module. As far as I know, B&M does not manipulate padding or markers. Maybe the maintainer of the AES module can help answer this.

polskikrol’s picture

Project: AES encryption » Backup and Migrate
Version: 7.x-1.x-dev » 7.x-2.2

Referring to the following snippets of code in includes/

function aes_encrypt

// Add a marker to the end of the data so we can trim the padding on decrpypt.
$data = pack("a*H2", $data, "80");

function aes_decrypt

// Trim all the padding zeros plus our non-zero marker.
$data = substr(rtrim($data, "\0"), 0, -1);

This extra manipulation of the aes encrypted backup does not make it accessible via other 3rd party aes tools. Im thinking of the need here to get access to a database backup w/o having to install a dummy instance of drupal and this module.

ronan’s picture

Huh, didn't realize that was in there. Haven't looked at that code in a while. To be honest I don't remember writing that and have no idea why it's there. I'll see if I can figure out how to remove it without breaking import for previously created backups.


Viybel’s picture

Version: 7.x-2.2 » 7.x-2.4
Priority: Normal » Critical

I realized this was a major problem when my database went corrupt. There was no way to recover my data from the AES encrypted dumps, apart from installing a Drupal from scratch and installing Backup & Migrate and AES modules plus some click and point manipulation.

This is definitely not a good recovery strategy!

Any Linux distribution has AES encryption/decryption tools that would allow to do all this in less than a minute. What's more the 'aespipe' tool (Ubuntu) does not give any feedback on whether the password is right, it just gives something resembling a decrypted file whatever password you give it. This means that anyone using B&M + AES can spend half an hour (like I did) trying to figure out why on earth the "decrypted" files are not valid bzip2/gzip files, before landing on this bug report.

Please remove the lines :

98    $data = pack("a*H2", $data, "80");


117   $data = substr(rtrim($data, "\0"), 0, -1);

from includes/

They make encrypted backups nearly unusable when you have a broken site, which defeats the purpose of having backups.

As for those who will have old AES backups, they should be given a simple php script that removes the padding, or maybe an option called something like "decrypt old encrypted files (legacy method)" on the bottom of the form.

It is urgent to stop corrupting encrypted backup files. That's why this bug should be considered as critical, IMO.

Sorry for the rant (data recovery situations are stressful) and keep up the good work: B&M is an amazing tool apart from this.


ronan’s picture

Category: bug » feature
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

The primary goal is that the backups be restorable with B&M. If I can play nice with other tools then that's a bonus. Therefore I am marking this as a feature request.

It would appear that the marker (which I must have taken from a comment on is because the php mcrypt function adds padding to the pre-encrypted data which would make the data unusable once decrypted unless I was reliably able to strip that padding.

I'm not sure I have enough knowledge of encryption to fix this ticket properly, and I certainly don't want to break anything. Do you know for sure that if I simply remove the marker then the files will be decryptable using aesutil or aespipe? I suspect that mcrypt_generic (which the AES module uses to encrypt the data) does not play nice with other tools (since it barely plays nice with itself). Can one of you confirm this by commenting out that line of code and testing the output with a 3rd party decryption tool?

If someone can give me another binary-safe way to deal with the PHP mcrypt padding that actually works with some tool other than PHP mcrypt_decrypt then I'll be happy to integrate it. Otherwise if you use encryption you will just have to use B&M for your restores.

ronan’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (works as designed)

I'm going to close this unless somebody has an idea of how to make it work.

ranelpadon’s picture

We encountered a similar use case: decrypt the AES-encrypted backup files via terminal and not in Drupal Admin UI. We ended up creating a stand-alone, custom PHP script that could be run in terminal. Our custom script successfully decrypted the files. See details here: