Return to Answer

quick update:

these encryption libraries are dynamically linked to the cspd MIPS ELF binary:

$ readelf --dyn-syms cspd | grep AES 484: 0053ab50 1248 FUNC GLOBAL DEFAULT 8 AES_set_encrypt_key 630: 0053b9d0 1600 FUNC GLOBAL DEFAULT 8 AES_decrypt 1187: 0050d470 552 FUNC GLOBAL DEFAULT 8 DecryByAES 1527: 0053b390 1600 FUNC GLOBAL DEFAULT 8 AES_encrypt 1535: 0053b030 864 FUNC GLOBAL DEFAULT 8 AES_set_decrypt_key 

as are these compression libraries:

$ readelf --dyn-syms cspd | grep compress 92: 0053c110 208 FUNC GLOBAL DEFAULT 8 uncompress 1064: 0053c010 216 FUNC GLOBAL DEFAULT 8 compress2 

uncompress and compress2 are associated with zlib.

Speaking of analyzing ciphertext, I though that this question on Security.SE was interesting: How to determine what type of encoding/encryption has been used?, especially the answer.

Speaking of analyzing ciphertext, I though that this question on Security.SE was interesting: How to determine what type of encoding/encryption has been used?, especially the answer.

quick update:

these encryption libraries are dynamically linked to the cspd MIPS ELF binary:

$ readelf --dyn-syms cspd | grep AES 484: 0053ab50 1248 FUNC GLOBAL DEFAULT 8 AES_set_encrypt_key 630: 0053b9d0 1600 FUNC GLOBAL DEFAULT 8 AES_decrypt 1187: 0050d470 552 FUNC GLOBAL DEFAULT 8 DecryByAES 1527: 0053b390 1600 FUNC GLOBAL DEFAULT 8 AES_encrypt 1535: 0053b030 864 FUNC GLOBAL DEFAULT 8 AES_set_decrypt_key 

as are these compression libraries:

$ readelf --dyn-syms cspd | grep compress 92: 0053c110 208 FUNC GLOBAL DEFAULT 8 uncompress 1064: 0053c010 216 FUNC GLOBAL DEFAULT 8 compress2 

uncompress and compress2 are associated with zlib.

The information regarding compression in the answers to this question on SO was also helpful: How to detect type of compression used on the file? (if no file extension is specified)

The information regarding compression in the answers to this question on SO was also helpful: How to detect type of compression used on the file? (if no file extension is specified)

By "file header", what I mean is the first 300 bytes or so (this question was used as a reference: RE Compressed backup file,router linux based so is it compresed with zlib? since this question, also by Vido, involved ZTE router firmware and its compression signature was found). Unfortunately, staring at a hex dump of the file did not yield any useful information.

Additionally, there is another RE.SE post titled ZTE encrypted backup config file regarding ZTE config backups of a different product, ZTE Speedport Entry 2i, that are also suspected of being encrypted. One the config.bin files shared in a link in the comments under this question also has similar header structure to H201LV2.0_Cur_config.bin but seems to be from an older firmware version. It appears that others are having difficulty with the same issue.

Differentiating between compression and encryption can be attempted using statistical methods. This has been discussed in the context of firmware analysis by devttys0 in 2 articles:

This speculation in the answer to ZTE encrypted backup config file may provide an avenue of investigation:

By "file header", what I mean is the first 300 bytes or so (this question was used as a reference: RE Compressed backup file,router linux based so is it compresed with zlib? since this question, also by Vido, involved ZTE router firmware and its compression signature was found). Unfortunately, staring at a hex dump of the file did not yield any useful information.

Additionally, there is another RE.SE post titled ZTE encrypted backup config file regarding ZTE config backups of a different product, ZTE Speedport Entry 2i, that are also suspected of being encrypted. One the config.bin files shared in a link in the comments under this question also has similar header structure to H201LV2.0_Cur_config.bin but seems to be from an older firmware version. It appears that others are having difficulty with the same issue.

Differentiating between compression and encryption can be attempted using statistical methods. This has been discussed in the context of firmware analysis by devttys0 in 2 articles:

This speculation in the answer to ZTE encrypted backup config file may provide an avenue of investigation: