8

I was poking around in ZTE Speedport Entry 2i (CPE used mostly in Germany, Slovakia etc, probably custom made for Deutsche Telekom). It's possible to download backup of config from UI.

I found out it's different from other ZTE config backups. Usually it's zlib compressed XML. I suspect this one has a layer of some pseudo-encryption on it.


00000000  99 99 99 99 44 44 44 44  55 55 55 55 aa aa aa aa  |....DDDDUUUU....|
00000010  00 00 00 00 00 00 00 00  00 00 00 04 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 40  |...............@|
00000040  00 02 00 00 00 00 00 80  00 00 57 c6 00 00 00 00  |..........W.....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  04 03 02 01 00 00 00 00  00 00 00 12 53 70 65 65  |............Spee|
00000090  64 70 6f 72 74 20 45 6e  74 72 79 20 32 69 01 02  |dport Entry 2i..|
000000a0  03 04 00 00 00 02 00 00  00 00 00 00 57 a8 00 01  |............W...|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 57 60 00 00  |............W`..|
000000e0  57 60 00 00 00 00 be d3  f7 b3 fe 9e 99 a4 35 75  |W`............5u|
000000f0  ce db 7f c2 99 17 43 7f  1e e2 54 7a 63 72 6f c8  |......C...Tzcro.|
00000100  b7 2d cc e8 cb 32 6c 3a  f0 fd 55 19 10 ac ea d5  |.-...2l:..U.....|
00000110  e9 18 01 01 71 7c 20 68  ca 66 d0 d9 f9 12 03 3d  |....q| h.f.....=|
00000120  ee bd ad 2a 00 e2 c1 96  73 12 bd 5a 94 3e 6d 1a  |...*....s..Z.>m.|
00000130  a8 7f c8 a8 8b 3d b6 1e  d8 ae 9b 43 63 6a e3 ea  |.....=.....Ccj..|
00000140  94 33 55 57 dc 81 b2 22  c5 e7 39 fd 75 b9 ba 5b  |.3UW..."..9.u..[|
00000150  00 ca a1 29 9b e2 9f bd  8e 1f 00 98 30 62 8b d7  |...)........0b..|
00000160  c6 12 ae ef 27 55 30 2a  4c f8 de 7c e5 2a 33 b9  |....'U0*L..|.*3.|
00000170  8b 32 4a d2 2c da 2a 18  ff 72 cf 1c 42 d8 41 6b  |.2J.,.*..r..B.Ak|

Other examples of this config can be found here: RE Compressed backup file,router linux based so is it compresed with zlib?

Is there a way to figure out how to extract content of this config? Is there a way how to detect if some sort of simple XOR encryption is in place?

I was unable to obtain firmware of the device, it's CPE so it's pretty locked down. The device itself looks to be using stripped down version similar to ZTE E5502 (same lua based web UI) E5502 firmware

You can download the config here. config.bin

Edit:

After reading something about difference between compression and entropy, I came to conclusion that the file is probably encrypted and not just obfuscated with something like XOR (because that doesn't change the entropy)

I obtained config file from another ZTE device (one with zlib compression)

$ binwalk -E -N config_f660.bin

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
1024          0x400           Rising entropy edge (0.973932)
10240         0x2800          Rising entropy edge (0.958898)
14336         0x3800          Rising entropy edge (0.966971)
17408         0x4400          Rising entropy edge (0.968328)

$ binwalk -E -N config_encrypted.bin

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
1024          0x400           Rising entropy edge (0.974513)
22528         0x5800          Falling entropy edge (0.737589)

As far as I can interpret this data is that the first rising edge is unencrypted header in both configs. In the compressed config other rising edges should represent compressed zlib blocks. If you actually plot the graph with binwalk you can see that there are still some rising edges in entropy but much smaller the line is almost flat. (Cannot include graphs due to low reputation). I'm now confident that's caused by applying encryption over those compressed zlib blocks.

Are my assumptions correct or am I missing something? Is there a method I could try to break or at least guess the encryption type without the firmware image?

  • I am not answring you question, but maybe this can help you. I have the same problem and i think we have same ecryption algoritm but diferrent keys. This is my config.bin I also find out, that a number 0x57 is often there maybe it can decide the sections. In my config file is 0xb6. Maybe it can be helpful for you to solve it. – lukas kiss Feb 17 '16 at 22:19
  • Thanks, I downloaded your config and the entropy looks very similar to mine that's true. Unfortunately I still haven't found any more info or ideas on how to solve this problem. – J91321 Mar 1 '16 at 21:58
  • Did you ever make any progress on this? I'm also looking at the config.bin from my new home router, from ZTE as well. – Juicy Sep 24 '16 at 18:13
  • Not really, I would probably need to obtain a sample of firmware and reverse engineer it to find out what is happening with config.bin. But if you are willing to share your config.bin sample I'll take a look. Just remember to remove any confidential information before exporting it. – J91321 Sep 24 '16 at 20:38
  • Firmware link seems to provide no firmware versions to download – NirIzr Oct 16 '16 at 18:38
5

I'm trying to hack a similar router (ZXHN H298N).

I took your config.bin and mine, the headers look pretty similar, as does lukas'... The key differences are the lengths of the files, and the name of the router in the 'magic area'.

Anyhow here's my efforts at decipher the header by hand:

-------- 1st 64 byte block --------                          
99999999 44444444 55555555 aaaaaaaa                          # zte magic number
00000000 00000000 00000004                                   # 4.. but what?
00000000 00000000 00000000                                   # 0
00000000 00000000 00000000                                   # 0
00000000 00000000 00000040                                   # 64, block size?
-------- 2nd 64 byte block --------
00020000                                                     # 131072 (block id?)
00000080                                                     # 128
000057c6                                                     # 22470 + 128 = 22598 = size of config.bin
00000000 00000000 00000000 00000000                          # 0
00000000 00000000 00000000 00000000                          # 0
00000000 00000000 00000000 00000000                          # 0
00000000                                                     # 0
-------- 34 byte magic area -------
04030201                                                     # start of magic area
00000000 00000012                                            # 18 (length of ASCII)
53706565 64706f72 7420456e 74727920 3269                     # Speedport Entry 2i
01020304                                                     # end of magic area
-------- 3rd 64 byte block --------
00000002                                                     # 2?
00000000 000057a8                                            # 22440
00010000                                                     # 65536 (block id?)
00000000 00000000 00000000 00000000                          # \
00000000 00000000 00000000 00000000                          #  } padding?
00000000 00000000                                            # /
00005760                                                     # 22368 = length of payload (encrypted?)
00005760                                                     # 22368 = length of payload (decrypted?)
-------- extra 4 bytes... ---------
00000000                                                     # 0
-------- vvv unknown vvv  ---------

I connected to my H298N router via serial connection and managed to dump out the flash from the bootloader, alas I don't know the root password otherwise I'd try to do some remote debugging, so offline disassembly is my only attack at the moment.

The unsquashed extract of the firmware is available here: https://github.com/streetster/zxhnh298n/tree/master/zxhnh298n_hv14_fv113_hyperoptic_firmware

As we've learnt from other theads on SE the cspd program is the one running on the router that controls everything.

Looking at cspd via mips-linux-gnu-objdump shows there are lots of interesting functions relating to cfg files:

$ mips-linux-gnu-objdump -T cspd | grep -i cfg | grep -i file
0051334c g    DF .text  0000034c dbcCfgFileUnsign
00506740 g    DF .text  00000240 dbFileLoadCfg
005118f0 g    DF .text  000005ec dbcCfgFileDecry
00510eac g    DF .text  000000f4 dbcCfgFileIsEncry
00513698 g    DF .text  000003dc dbcCfgFileSign
00512b74 g    DF .text  0000001c dbcCfgFileEncry
0050e2dc g    DF .text  000004b4 dbcCfgFileVersion

Extracting the assembly for these functions is possible using mips-linux-gnu-objdump -D -S cspd, but I'm struggling to get something more human readable at this point, thus I've been doing some experiments to try to get closer to the solution.

I believe that the configuration file is encrypted with AES, evidence for this is the AES-related functions:

$ mips-linux-gnu-objdump -T cspd | grep -i aes
00576620      DF *UND*  00000000 AES_set_encrypt_key
00576450      DF *UND*  00000000 AES_decrypt
005113d0 g    DF .text  00000228 DecryByAES
00575970      DF *UND*  00000000 AES_encrypt
00575950      DF *UND*  00000000 AES_set_decrypt_key

I also think that the CRC of the configuration file plays a part in the encryption, potentially some part of the key, as CRC32 only generates a 32bit hash, and AES uses 128bit (or 192/256), therefore the CRC is too short to be the whole 128bit key (assuming 128bit key length!):

$ mips-linux-gnu-objdump -T cspd | grep -i crc
005115f8 g    DF .text  000002f8 DecryByCRC
00510ce0 g    DF .text  000001cc dbFileCRCSame

If the xml configuration is saved down and encrypted with AES in ECB mode, with the same key each time, then I would expect a 1 character change to the configuration (e.g. changing my admin password from "password" to "qassword") to result in the config.bin looking the same apart from a single 16 byte block where the "p" was a "q" and thus the encryption resulted in a different 16 byte block.

If the encryption uses AES in CBC mode, then I would expect that the config.bin would look the same up to the point in the file where the "p" was a "q", and then the rest of the file would be different due to the nature of CBC.

However... a change of "p" to "q" results in pretty much the entire file changing (there is a 32 byte segment which remains constant, I've looked at the config.bin of other H298N routers and it matches exactly!)

The config.bin is an extra 16 bytes longer with "qassword", 16 bytes being the blocksize for AES...

password versus qassword

If the xml file is first compressed (e.g. with zlib per other ZTE routers) before encryption then the contents of the files would still look very similar up to the point where the "a" changed to a "b" (based on a quick test of compressing two files with 1 char difference), so I do not think that this is responsible for the difference in content, but could very well explain the difference in length.

Also, changing another field (e.g. turning a particular setting on or off (1 or 0)) still results in a completely different config.bin, which rules out the idea that some hash of the password is being used as the key...

Next step is to try to brute force AES decryption using the 32 bytes at offset 0xDE and see if I get anywhere.

I imagine that the core functionality to perform the encryption is the same across the ZTE routers (common config.bin header suggests this), so imagine it's just a case of figuring out the precise method, and what keys/IV are used to decrypt it again...

0

In order to get key you need to check CSPDBGetFileEncryKey function

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.