They could at the very least release specification for the file format. It's not like they need it anymore. It's abandoned, so release the spec.
Another positive upside of that approach would be that developers might be slightly more likely to design a file format specification, a task it seems they sometimes approach rather haphazardly (brow furrowed in Microsoft's direction circa 1995).
As for decrypting those files, I can't help you, but if you wan to encrypt files on OS X it's pretty easy with OpenSSL:
openssl <cipher> -salt -in <path to file to encrypt> -out <path specifying where file should be saved>
Where <cipher> is one of: aes-128-cbc, aes-128-ecb, aes-192-cbc, aes-192-ecb, aes-256-cbc, aes-256-ecb, base64, bf, bf-cbc, bf-cfb, bf-ecb, bf-ofb, camellia-128-cbc, camellia-128-ecb, camellia-192-cbc, camellia-192-ecb, camellia-256-cbc, camellia-256-ecb, cast, cast-cbc, cast5-cbc, cast5-cfb, cast5-ecb, cast5-ofb, des, des-cbc, des-cfb, des-ecb, des-ede, des-ede-cbc, des-ede-cfb, des-ede-ofb, des-ede3, des-ede3-cbc, des-ede3-cfb, des-ede3-ofb, des-ofb, des3, desx, idea, idea-cbc, idea-cfb, idea-ecb, idea-ofb, rc2, rc2-40-cbc, rc2-64-cbc, rc2-cbc, rc2-cfb, rc2-ecb, rc2-ofb, rc4, rc4-40, seed, seed-cbc, seed-cfb, seed-ecb, seed-ofb, or zlib, although some of those will do neither what you expect nor anything useful in this context. I recommend aes-128-cbc.
openssl <cipher> -d -in <path to file to decrypt> -out <path specifying where the decrypted file should be saved>
NOTE: I suspect but cannot immediately prove that openssl generates the AES encryption key using the sha1 hashing algorithm. Your mileage may vary.