MirrorFolder can encrypt files in AESCrypt file format on-the-fly when copying files from the source to mirror path, i.e., it reads a chunk of file data in memory, encrypts that data, and then writes the encrypted data to the destination file. It can also decrypt files in the same way. We are using the AES File Format specification v2 as described on that website (but not any code from that project). So, you can use the AESCrypt utility program from that website to decrypt files if needed. Note that you can also encrypt or decrypt files under the Restore page when copying files from a source to destination path.Below is a copy of the AES file format v2 used by MirrorFolder.

 3 Octets - 'AES'
 1 Octet  - 0x02 (Version)
 1 Octet  - Reserved (set to 0x00)
 .... Start of repeating extension block section
 2 Octet  - Length in octets (in network byte order) of an extension
            identifier and contents.  If 0x0000, then no further
            extensions exist and the next octet is the start of the
            Initialization Vector (IV).  Following an extension,
            this length indicator would appear again to indicate
            presence or absence of another extension and the size of
            any such extension.
nn Octets - Extension identifier.  This is either a URI or an
            identifier defined by the AES developer community and
            documented on the standard extensions page, either
            of which is terminated by a single 0x00 octet.  All
            extension identifiers are case sensitive.
              MirrorFolder inserts the following URI:
                 urn:uuid:7EB104C5-C965-4DE9-ACFC-F9161D54DEBA
              Then the following fields:              
               8 Octets - File size in bytes.
               8 Octets - File modification time in Windows UTC format.
               8 Octets - File creation time in Windows UTC format.
                 A URI was used to allow anybody to define extension
                 types, though we should strive to define a standard
                 set of extensions.
              Examples of standard extension identifiers:
                 CREATED-DATE
                 CREATED-BY
            A special extension is defined that has no name, but is
            merely a "container" for extensions to be added after the
            AES file is initially created.  Such an extension avoids
            the need to read and re-write the entire file in order to
            add a small extension.  Software tools that create AES
            files should insert a 128-octet "container" extension,
            placing a 0x00 in the first octet of the extension
            identifier field.  Developers may then insert extensions
            into this "container" area and reduce the size of this
            "container" as necessary.  If larger extensions are added
            or the "container" area is filled entirely, then reading
            and re-writing the entire file would be necessary to add
            additional extensions.
nn Octets - The contents of the extension
.... End of repeating extension block section
16 Octets - Initialization Vector (IV) used for encrypting the
            IV and symmetric key that is actually used to encrypt
            the bulk of the plaintext file.
48 Octets - Encrypted IV and 256-bit AES key used to encrypt the
            bulk of the file
            16 octets - initialization vector
            32 octets - encryption key
32 Octets - HMAC
nn Octets - Encrypted message (2^64 octets max)
 1 Octet  - File size modulo 16 in least significant bit positions
32 Octets - HMAC

This is our own file format that uses the AES-256/GCM algorithm for encrypting file data and a password- based key derivation algorithm like PBKDF2 for generating the encryption key. This file format has the following characteristics:

• File meta-data is encrypted and saved in the header.
• File data is encrypted in fixed size blocks with authentication data. So, it is possible to read and decrypt any such data block randomly, enabling random access to the encrypted file.
• Saves key derivation and encryption algorithm names in the header. So, different algorithms can be supported.
• It also saves the encryption information header at the end of the file as associated data for the last encrypted data block. So, it is possible to decrypt the file even if the file header is lost.

Below is the AEG File format used by MirrorFolder.

 3 Octets - 'AEG'
 1 Octet  - 0x01 (Version)
 2 Octets - Two bytes unsigned integer in little-endian order, representing the
            total size of the encryption information block and the file meta-data
            block in bytes. Encrypted file data starts at the end of this block.
            MirrorFolder uses a 4096 bytes fixed-size block for it now.
 1 Octet  - Length of the key derivation and encryption algorithm names in bytes.
nn Octets - Name of the key derivation algorithm followed by its parameters
            separated by commas. Then the name of the encryption algorithm
            proceeded by a semicolon. Currently, MirrorFolder uses PBKDF2 with
            10,000 iterations for key derivation and AES-256/GCM as encryption
            algorithm. So, this string will look like:
            PBKDF2-HMAC-SHA-256,10000;AES-256/GCM
 1 Octet  - Length of the salt in bytes to follow.
nn Octets - An array of salt bytes. MirrorFolder currently uses a 16-byte salt.
 2 Octets - Length of the encrypted meta-data in bytes including a 16-byte HMAC. 
            This is a 2-byte unsigned integer in little-endian order.            
nn Octets - Encrypted meta-data for the file. MirrorFoler currently saves the
            following meta-data as a key/value pair for a file.
            date_modified - The last modification time for a file.
            date_created - The creation time for a file.
            file_size - The file size in bytes.
            file_name - The file name in UTF-8 character set.
            These meta-data is encrypted and saved with its HMAC value.
            MirrorFolder uses he proceeding encryption information block
            as associated data when calculating the HMAC.
nn Octets - Encrypted file data in 4096 octets blocks. The last block
            can be less than 4096 octets.
64 Octets - Footer block to be appended to the last encrypted block as
            associated data. First two octets contains the length of 
            this block. Then the key derivation and encryption algorithm 
            names followed by the salts just as they are in the file header.