Tally ERP 9 is a “new-age business management software for new-age businesses” that is “tailor-made to delight”. With more than two million users, Tally is one of the most popular tools of its kind in India. The product includes the company’s implementation of secure storage named Tally Vault. How secure is Tally Vault, and what does one need to break in? In this article, we’ve provided some insights on how ElcomSoft researchers work when adding support for a new file format.

Support for Tally Vault is available since Elcomsoft Distributed Password Recovery 4.20.

Breaking Tally Vault

Tally Vault can be protected with a password. The password can be configured at the time one adds a new company; it is also possible to assign a password at a later time.

Once the password is set, ERP 9 creates a new protected vault. The old one (if any) can be deleted. If both encrypted and unencrypted versions of the company profile exist, one can select the right profile.

The new versions of Tally ERP 9 store the data in the following folder:

c:\Users\Public\Tally.ERP9\Data\(1nnnn)

If a password is specified for Tally Vault, the product encrypts all files with the .900 extensions that are over 512 bytes in size. However, the majority of the data is stored in a single file named Company.900. This file also stores information about the users if the “Use security control” option is enabled.

Unencrypted data is represented in the following way:

Once encrypted, the data looks as follows:

The file is comprised of 512-byte blocks. Each block starts with a 4-byte (32-bit) CRC checksum. When verifying the block, the tool calculates a CRC of the rest of the data (512 bytes less the 4-byte CRC) and compares the result with the checksum.

Now to the encryption. Tally uses an encryption algorithm derived from DES with a 64-bit encryption key. The DES algorithm used to be an industry standard originally introduced in 1977; in 2001, DES was superseded by AES, which is still used today. The 64-bit encryption key is derived straight from the user’s password (the concept of separate Media Encryption and Key Encryption keys is never heard of). Moreover, a slight modification of the user’s password leads to a similarly slight modification of the encryption key, which suggests a horribly weak implementation of key derivation. Considering that cryptographically strong hash functions (e.g. SHA-512) exist for a very long time, this result is truly amazing (as in “amazingly bad”). The encryption deals with 8-byte blocks.

Verifying the password is implemented by calculating the encryption key, decrypting the encrypted page and calculating the CRC of the decrypted data. The CRC is then compared with the check sum stored at the beginning of the page. Theoretically, decrypting the page and verifying the password would require decrypting some 64 blocks of 8 bytes each.

Reality is different. Each page includes a few bytes of fixed metadata. For example, immediately following the CRC there are four bytes containing the fixed value of 0x00000001. This is what’s considered a “known plain text”. As a result, the attacker does not have to decrypt the entire 512-byte page or calculate its checksum. Instead, decrypting the 4 bytes and comparing them with a known value of 0x00000001 is enough to try a password. Of course, collisions are unavoidable; for this reason, once the fixed four bytes are successfully decrypted, the attacker must verify the rest of the content by following the original algorithm (e.g. decrypting the entire page and calculating its CRC).

This value is not the only fixed metadata stored in encrypted pages. The offset 12 apparently stores the page number (unless it’s the last page), so even if Tally fixes this issue, other possibilities for fast attacks would remain.

So how does the speed of the known plaintext attack compare to the speed of the more straightforward attack that requires decrypting the whole page?

Conclusion

The “tailor-made to delight” software for “new-age businesses” delivers the worst implementation of data protection we’ve seen in the last 20 years. It’s so bad we don’t know where to start from; there is no single aspect that’s done right. The encryption key is directly derived from the user’s password instead of using separate media encryption and key encryption keys. The homegrown algorithm deriving the encryption key from the user’s password is weak beyond imaginable; we couldn’t write as bad a hash function even if we tried. The DES-like encryption algorithm is outdated, while the 64-bit encryption key is way too short considering the outdated encryption algorithm. The known plain text metadata embedded in every encrypted page is icing on the cake. We just hope that new-age businesses will remain delighted if their encrypted data falls into the wrong hands.