识别此ZTE ZXV10 H201L V2备份配置文件的压缩

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 4c 84 00 00 00 00  |..........L.....|
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 10 5a 58 56 31  |............ZXV1|
00000090  30 20 48 32 30 31 4c 20  56 32 2e 30 01 02 03 04  |0 H201L V2.0....|
000000a0  00 00 00 02 00 00 00 00  00 00 4c 68 00 01 00 00  |..........Lh....|
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 4c 20 00 00 4c 20  |..........L ..L |
000000e0  00 00 00 00 5d a2 a4 6e  d6 94 bc 97 07 1b 38 17  |....]..n......8.|
000000f0  ab 66 e7 bc f4 9b 4e 3f  cd 89 b0 c3 b2 11 4a f4  |.f....N?......J.|
00000100  40 88 2c a1 90 e4 4d 32  d7 9b fa bd ec 39 42 ae  |@.,...M2.....9B.|
00000110  e6 a9 2f 26 03 6e 70 f4  e5 0f 88 55 3b 1c b0 bb  |../&.np....U;...|
00000120  b6 04 3e 73 99 15 ef 65  39 8d 85 52 6e 37 0b 5d  |..>s...e9..Rn7.]|
00000130  6e c2 39 75 a4 94 0c c7  79 72 86 dc 25 38 38 e0  |n.9u....yr..%88.|
00000140  8f 54 5b 18 a4 76 15 e4  f7 b3 c6 0f d8 91 19 e0  |.T[..v..........|
00000150  00 22 1d 9c 7d a0 08 42  6f 87 ab 73 4b 17 4c 25  |."..}..Bo..sK.L%|
00000160  40 2f ea 30 6b 80 27 72  db 2b 30 7a 2a 2f 3d b0  |@/.0k.'r.+0z*/=.|
00000170  46 ca 50 0e ad 99 9a 70  3e 23 b4 b4 e0 ee 3a b3  |F.P....p>#....:.|
00000180  a8 6a 9d 7c a2 29 17 51  9f 7a 0a 14 90 41 3f e2  |.j.|.).Q.z...A?.|
00000190  dc 63 52 c8 01 24 6b 46  31 ac 4e c6 54 cb 18 70  |.cR..$kF1.N.T..p|
000001a0  33 67 0c 06 7e db 00 af  22 ec a1 37 98 01 ef ae  |3g..~..."..7....|
000001b0  9b 47 30 48 e3 6d 18 87  ab 34 2d 2b 4e b9 5b eb  |.G0H.m...4-+N.[.|
000001c0  55 5f 61 ab da eb 39 7e  df 7e 79 fe fd f8 11 66  |U_a...9~.~y....f|
000001d0  b3 48 fc f8 33 38 fd 1b  1d 00 bd 83 f8 b8 2b 9f  |.H..38........+.|
000001e0  cf 1e ae 69 ff 5d e3 04  8c 6d cc 19 12 f4 95 03  |...i.]...m......|
000001f0  3d c8 67 e2 c2 52 d3 a4  44 eb af f5 a0 63 0a ef  |=.g..R..D....c..|
00000200  d2 3d 82 9e 95 d1 f4 1c  ce 0c 5f 60 49 ab c3 d5  |.=........_`I...|
00000210  89 d5 53 82 f7 4e ba ae  d3 3c 09 e9 af 52 29 e9  |..S..N...<...R).|
00000220  d5 9b 02 54 91 e9 ae 0e  12 26 3b ca ca 4e 8f 01  |...T.....&;..N..|
00000230  a4 52 e1 4e f8 42 7e 0d  9c 99 76 7d 5f 3c de 67  |.R.N.B~...v}_<.g|
00000240  82 fc 38 97 7b db 06 b3  0a 44 95 64 ab 02 71 1a  |..8.{....D.d..q.|
00000250  08 cc ca 88 f8 b6 bb 12  d4 fd 4d dd 9b 3f c1 57  |..........M..?.W|
00000260  bb 54 9c b7 99 c3 9c 69  86 91 ea 82 b7 38 b3 c1  |.T.....i.....8..|
00000270  f3 71 30 b7 06 82 ea c3  04 93 30 d4 83 56 50 b5  |.q0.......0..VP.|
00000280  93 39 7a ea a7 1b 38 f0  3a f0 95 57 cb 79 e2 91  |.9z...8.:..W.y..|

#1 楼

最新ZTE路由器config.bin的加密是AES ECB（电子密码本）。密钥存储在字符串/bin/cspd旁边的/cfg/db_backup_cfg.xml中。负责的功能是CspDBInitPdtInterface，最后一次snprintf调用。如果缺少128位，则密钥为零填充。

密钥对于ISP可能是非常独特的：您的H201L V2为Renjx%2$CjM，行人的H298N V1.4为Wj%2$CjM（但不起作用） ，本地H118N V2.3的版本为MIK@0STzKpB%qJZf。

#2 楼

假设：文件已加密

1。缺少压缩签名Binwalk检测到的相关压缩格式如下：bzip2，lzop，lzip，lrzip，LZO，7z，gzip，rzip，LZMA，zlib和LZ4。由于针对H201LV2.0_Cur_config.bin运行Binwalk不会返回任何结果，即使Binwalk通常会认识到这些压缩格式中的任何一种都是进行压缩以外或进行压缩的第一个指标。 ，因此我尝试通过使用zenhax.com论坛帖子“如何用肉眼识别压缩算法”中的信息，在文件标题中查找手动指示压缩字节序列开头的字节序列，寻找Bzip2，zlib， gzip，LZMA，LZMA 86头，LZMA 86 dec，LZMA 86 dec头，LZMA efs，LZMA无头，LZMA2和LZMA2无头压缩签名尤其如此。以下是每个压缩签名的前几个字节：


zlib：78 da

gzip：1f 8b
LZMA，LZMA 86头，LZMA 86 dec头，LZMA 86 dec头，LZMA efs：5d 00 00 00

LZMA无接头：00 44 94 a6

LZMA2：18 e0 07 ce

LZMA2无接头：e0 07 ce 02 <关于SO的此问题的答案中有关压缩的信息也很有帮助：如何检测文件上使用的压缩类型？ （如果未指定文件扩展名）

通过“文件头”，我的意思是前300个字节左右（此问题用作参考：RE压缩备份文件，基于linux的路由器，因此它由zlib压缩吗？因为这个问题（也是由Vido提出的）涉及ZTE路由器固件并找到了其压缩签名）。不幸的是，盯着文件的十六进制转储不会产生任何有用的信息。

2。来自其他来源的证据

在Montenegrin论坛上名为ZTE zxv10 h201的线程的页面3中包含一些相关帖子以及该错误的python脚本： br />

import re
import sys
import zlib
import struct

ime_fajla = 'H201LV2.0_Cur_config.bin'

def extract_config_xml(config_bin):
    config_xml = b''
    for zlib_chunk in re.finditer('\x78\xda', config_bin):
        zlib_chunk_start = zlib_chunk.start()
        zlib_chunk_header = config_bin[zlib_chunk_start - 12: zlib_chunk_start]
        xml_chunk_length, zlib_chunk_length, config_bin_length = \
            struct.unpack('>LLL', zlib_chunk_header)
        if xml_chunk_length == 0x10000 or config_bin_length == 0:
            zlib_chunk_end = zlib_chunk_start + zlib_chunk_length
            zlib_chunk = config_bin[zlib_chunk_start: zlib_chunk_end]
            xml_chunk = zlib.decompress(zlib_chunk)
            assert xml_chunk_length == len(xml_chunk)
            config_xml += xml_chunk
    return config_xml

with open(ime_fajla, 'rb') as f:
    print extract_config_xml(f.read())

在这种情况下，此脚本无济于事，主要是因为它搜索字节序78 da（zlib压缩签名），该字节序列不在相关文件中， H201LV2.0_Cur_config.bin。

相似的config.bin文件非常稀缺且很难找到，但已找到并调查了其中的一些文件。最有趣和有用的是通过DropBox共享的名为H201LV2.0.bin的文件。这是两个文件的标头的区别：文件真的被加密了吗？这看起来很奇怪）：



当Binwalk针对0x00003214运行时，同样也失败了：

# decompress.py
import re
import sys
import zlib
import struct


filename = "H201LV2.0_Cur_config.bin"
def extract_config_xml (filename):
    config_xml = b''
    for zlib_chunk in re.finditer ('\x78\xda', filename):
        zlib_chunk_start, zlib_chunk.start = ()
        zlib_chunk_header = filename[zlib_chunk_start - 12: zlib_chunk_start]
        xml_chunk_length, zlib_chunk_length, config_bin_length, \
            struct.unpack ('> LLL', zlib_chunk_header)
        if xml_chunk_length == 0x10000 or config_bin_length == 0:
            zlib_chunk_end = zlib_chunk_start + zlib_chunk_length
            zlib_chunk = filename[zlib_chunk_start: zlib_chunk_end]
            xml_chunk = zlib.decompress(zlib_chunk)
            assert xml_chunk_length == len(xml_chunk)
            config_xml += xml_chunk
    return config_xml

with open (filename, 'rb') as f:
    print extract_config_xml(f.read())

此外，还有另一个RE.SE帖子，标题为ZTE加密备份配置文件，涉及另一个产品ZTE Speedport Entry 2i的ZTE配置备份，也被怀疑是加密的。在此问题下的注释链接中共享的config.bin文件也具有与H201LV2.0.bin类似的头结构，但似乎来自较旧的固件版本。看来其他人在遇到相同问题时遇到困难。

3。数据熵和熵分析

SE超级用户博客上有一篇有趣的关于压缩和加密的文章。这是文本的两点：



压缩搜索模式，并用代表这些模式的较小标记替换它们。
加密将数据混淆，理想情况下使用以下方法创建输出：里面没有可辨认的图案



可以使用统计方法尝试区分压缩和加密。在2条文章中，devttys0在固件分析的上下文中对此进行了讨论：


使用数学方法从压缩中区分加密
加密与压缩，第2部分/>从第一篇文章开始：


...可以进行一些测试来量化数据的随机性。我发现最有用的两个是卡方分布和蒙特卡洛pi近似。这些测试可用于测量数据的随机性，并且与视觉熵分析相比，对随机性偏差更敏感。现有的工具（例如ent）将为我们执行这些
计算。真正的问题是如何解释结果；
加密数据与压缩数据的随机性如何？这将取决于
所使用的加密/压缩以及数据集的大小
（更多数据通常意味着更准确的结果）。将这些
测试应用于大小不同的文件样本（该样本很小），已通过不同的压缩/加密算法
进行了分析。
卡方分布中的较大偏差或蒙特卡洛近似中的较大误差百分比是压缩的确定符号。
pi计算非常准确（误差<.01％）是确定符号。
较低的chi值（<300）和较高的pi误差（> .03％）表示压缩。
较高的chi值（> 300）和较低的pi误差（<.03％）表示加密。




这些值范围可以用作文件分析中的启发式方法。

这是使用Binwalk对H201LV2.0_Cur_config.bin进行熵分析的结果：

$ binwalk H201LV2.0.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

H201LV2.0_Cur_config.bin：

$ binwalk -E -J H201LV2.0_Cur_config.bin 

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
1024          0x400           Rising entropy edge (0.972587)

简介：根据图表，字节偏移量（十进制）〜1000到〜19000之间的熵分布相当均匀。对于加密的数据，这是预期的：


加密的数据通常是一条没有变化的扁平线。误差为0.26。根据devttys0，卡方值已达到加密数据所期望的目标，但pi错误值与目标相差很远： pi错误（<.03％）是
表示加密。我们知道没有加密。从分析中排除已知未加密的数据将提高准确性。加密似乎始于偏移量ent，因此可以编写python脚本以跳过前292个字节，并将其余字节写入辅助文件：
现在，可以仅对（怀疑的）加密数据块执行分析，而无需使用未加密的文件头：

这些结果很有趣：该图表明整个文件中的熵近似均匀，但是现在卡方分布（256.03）和pi近似误差（0.07％）为都在压缩数据预期的范围内！


较低的chi值（<300）和较高的pi误差（> .03％）表示压缩。


话虽如此，这些新值相对接近其各自的边界条件。也就是说，对于卡方分布，256.03相对接近300的边界条件，对于pi近似误差，0.07％相对接近0.03％的边界条件，因此很难自信地说文件确实是加密的或如果基于此压缩。

结论

熵分析的一些结果混淆了支持文件加密的假设的证据。因此，我敢冒险对文件进行加密，但是无法使用此处描述的方法对其进行证明。文件。

建议，其他途径


您是否对我应该尝试的方法有建议？ />

1。更加严格的统计分析

熵分析虽然有用，但还不够；应当使用其他统计方法：


信息熵通常用作随机性的初步检验。一般而言，随机数据将具有较高的信息熵，而较低的信息熵则是数据不是随机数据的良好指示。 （低水平的熵并不是确定数据不是随机的绝对证据，但这意味着您应该
保持怀疑，并将生成器提交给进一步的测试。） >但是，逆关系不成立，这意味着高度的信息熵不能保证随机性。例如，一个
压缩文件（例如一个ZIP文件）具有很高的信息熵，但实际上是高度结构化的，它将使许多其他
随机测试失败。因此，您必须谨慎使用
信息熵作为随机性的度量。为了获得有意义的结果，您确实需要将其与其他测试结合起来。


2。恢复加密模块

中兴通讯加密备份配置文件答案中的这种推测可能提供了调查的途径：


我想可以执行的核心功能中兴路透社的加密方式相同（常见的config.bin建议这样做），因此可以想象这只是弄清楚该方法的情况，以及使用什么密钥/ iv再次对其进行解密...


如果在固件中找到负责执行加密的模块，则可以对加密算法进行逆向工程。考虑到缺少容易获得的中兴路由器固件映像，我认为需要访问设备。

3。密文分析

我没有追求的是使用bfcrypt或FindCrypt之类的工具对（可疑）密文进行分析，以确定用于加密文件的加密算法。可以在fwhacking.blogspot.com.br上找到更多工具的列表。

说到分析密文，尽管如此，有关Security.SE的问题很有趣：如何确定编码类型已使用加密吗？，特别是答案。


快速更新：

这些加密库动态链接到0x00000124 MIPS ELF二进制文件：

$ ent H201LV2.0_Cur_config.bin
Entropy = 7.981641 bits per byte.

Optimum compression would reduce the size
of this 19716 byte file by 0 percent.

Chi square distribution for 19716 samples is 650.33, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 126.7613 (127.5 = random).
Monte Carlo value for Pi is 3.133292757 (error 0.26 percent).
Serial correlation coefficient is 0.039397 (totally uncorrelated = 0.0).

这些压缩库也是如此：

#!/usr/lib/python

with open("H201LV2.0_Cur_config.bin", "rb") as input_file:
    with open("auxiliary_H201LV2.0_Cur_config.bin", "wb") as output_file:
        output_file.write(input_file.read()[292:])

ent和cspd与zlib关联。

#3 楼

遇到这些密钥并共享

已知的AES密钥：

  zxhn h118n ert5                      - 'MIK@0STzKpB%qJZe'
  zxhn h118n V2.1.3_ROSCNT?            - 'MIK@0STzKpB%qJZf'
  zxhn h168n v3                        - '402c38de39bed665'
  zxhn h298n hv17_fv116_mts?t1         - 'Wj' (due to bug, orig. is 'Wj%2$CjM')
  zxhn h298a hw1.1.20_fw1.1.20_ros_t1? - 'm8@96&ZG3Nm7N&Iz'
  zxhn h108n hw1.2_fw2.5.4_eg1t8_ted,
  zxhn h108n hv11_fv2_5_4_*            - 'GrWM2Hz&LTvz&f^5'
  zxhn h168n hv10_fv310t3_belt         - 'GrWM3Hz&LTvz&f^9'
  zxhn h208n hv10_fv1010_belt16t1      - 'Renjx%2$CjM'
  zxhn h267n hv10_fv100t3_belt         - 'tHG@Ti&GVh@ql3XN'

#4 楼

在我的路由器ZTEZXV10 H201L V2上，有一个实用程序可负责db dackup的使用，并可以租用它，也许有人可以“看到”他们如何加密baykup。