我发现它与其他ZTE配置备份不同。通常是zlib压缩的XML。我怀疑这上面有一层伪加密。所以zlib包含它吗？
是否有办法弄清楚如何提取此配置的内容？有没有办法检测某种简单的XOR加密是否到位？
我无法获得该设备的固件，它是CPE，因此已被锁定。设备本身似乎正在使用类似于ZTE E5502（基于Lua的Web UI）E5502固件的精简版本。您可以在此处下载配置。 config.bin
编辑：
在阅读了有关压缩和熵之间的区别之后，我得出的结论是该文件可能是加密的，而不仅仅是被XOR（因为那不会改变熵）
我从另一台ZTE设备（使用zlib压缩的设备）获得了配置文件。
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|
正如我可以解释的那样，这两个配置中的第一个上升沿是未加密的标头。在压缩配置中，其他上升沿应表示压缩的zlib块。如果您实际使用binwalk绘制图形，您会看到熵中仍然存在一些上升沿，但更小的直线几乎是平坦的。 （由于信誉低，不能包含图表）。我现在确信这是由于对这些压缩的zlib块进行加密所致。
我的假设正确吗？有没有我可以尝试破坏或至少猜测没有固件映像的加密类型的方法？
#1 楼
据2020年8月更新：据我所知，以下信息准确无误。在编写本文时，它已用于解密2个不同路由器上的
config.bin。配置文件的混淆部分是一系列ZLIB压缩的部分，已使用AES在ECB模式下使用一个16字节的密钥。
路由器上有一个名为
cspd的应用程序，它执行许多不同的操作。其中之一是加密/解密配置文件。一些中兴路由器将AES密钥硬编码到
cspd二进制文件中。其中一些没有。不幸的是，您却没有。cspd中有一个名为PdtDBSetAESEncryKey（由Ghidra提供的代码）的函数，用于设置密钥：undefined4 PdtDBSetAESEncryKey(char *param_1,int param_2)
{
byte bVar1;
char cVar2;
undefined4 uVar3;
int iVar4;
size_t sVar5;
undefined4 *puVar6;
undefined4 *puVar7;
byte bVar8;
undefined4 local_48;
undefined4 local_44;
undefined4 local_40;
undefined4 local_3c;
undefined4 local_38;
undefined local_18;
local_48 = 0;
local_44 = 0;
local_40 = 0;
local_3c = 0;
memset(&local_38,0,0x21);
uVar3 = 0xffffffff;
if ((param_1 != (char *)0x0) && (param_2 != 0)) {
iVar4 = _getTagparamMD5(&local_48);
if (iVar4 != 0) {
ProcUserLog("dbc_mgr_pdt_encry.c",0x9c,"PdtDBSetAESEncryKey",5,0,0,
"_getTagparamMD5 failed! Use default");
sVar5 = strlen("Hello! world,");
CspGetMD5("Hello! world,",sVar5,&local_48);
}
puVar7 = &local_48;
puVar6 = &local_38;
do {
bVar1 = *(byte *)puVar7 >> 4;
if (bVar1 < 10) {
cVar2 = '0';
}
else {
cVar2 = 'W';
}
bVar8 = *(byte *)puVar7 & 0xf;
*(byte *)puVar6 = bVar1 + cVar2;
if (bVar8 < 10) {
bVar8 = bVar8 + 0x30;
}
else {
bVar8 = bVar8 + 0x57;
}
puVar7 = (undefined4 *)((int)puVar7 + 1);
*(byte *)((int)puVar6 + 1) = bVar8;
puVar6 = (undefined4 *)((int)puVar6 + 2);
} while (puVar7 != &local_38);
local_18 = 0;
strncpy(param_1,(char *)&local_38,param_2 - 1);
uVar3 = 0;
}
return uVar3;
}
其中：
读取名为
tagparam_m的文件并生成其内容的MD5； _getTagparamMD5() 如果此功能失败，则使用
'Hello! world,'的MD5代替； iVar4 != 0 将MD5转换为（小写的）十六进制摘要； （do循环）
此密钥从
libcrypto被馈送到设置密钥功能AES_set_decrypt_key，第二个参数（“位”）设置为128（即16字节KEY_LENGTH）。 /> tagparam_m文件位于/var中，并且是在路由器启动时创建的。我已经看到了此文件的两个示例。每个数据条目前面都有一个迷你标头，包括：
2字节标识符
2字节长度和
2字节填充。
示例1：
0100 0006 0000 // 0100: MAC 0, 0006: 6 bytes, 0000: padding
aabb ccdd eef2 // MAC Address 0 (raw hex)
0101 0006 0000 // 0101: MAC 1, 0006: 6 bytes, 0000: padding
aabb ccdd eef3 // MAC address 1 (raw hex)
0102 0006 0000 // .. etc
aabb ccdd eef4
0103 0006 0000
aabb ccdd eef5
0104 0006 0000
aabb ccdd eef6
0105 0006 0000
aabb ccdd eef7
0106 0006 0000
aabb ccdd eef8
0107 0006 0000
aabb ccdd eef9
0108 0006 0000
aabb ccdd eefa
0109 0006 0000
aabb ccdd eefb
0200 000f 0000 // 0200: Serial No, 000f: 15 bytes, 0000: padding
4142434445464748494a4b4c4d4e4f // Serial Number (ASCII)
0400 000e 0000 // 0400: BSSID, 000e: 14 bytes, 0000: padding
4142434445464748494a4b4c4d4e // BSSID (ASCII)
0510 0010 0000 // 0501: BSSID Password, 0010: 16 bytes, 0000: padding
4142434445464748494a4b4c4d4e4f50 // BSSID Password (ASCII)
0601 0005 0000 // 0601: Admin Username, 0005: 5 bytes, 0000: padding
4142434445 // Username (ASCII)
0701 0008 0000 // 0701: Admin Password, 0008: 8 bytes, 0000: padding
4142434445464748 // Password (ASCII)
0300 0006 0000 // 0300: Manufacturer MAC, 0006: 6 bytes, 0000: padding
414243444546 // Manufacturer MAC (ASCII)
0806 0006 0000 // 0806: Hardware revision
5631 2e30 2e30 // Hardware revision (ASCII)
0807 0001 0000 // 0807: Trailer?
30 // "0" ASCII
示例2：
0100 0006 0000 // 0100: MAC 0, 6 bytes
5078 b3aa bbc0 // 50:78:b3:aa:bb:c0
0101 0006 0000 // 0101: MAC 1, 6 bytes
5078 b3aa bbc1 // 50:78:b3:aa:bb:c1
0102 0006 0000 // 0102: MAC 2, 6 bytes
5078 b3aa bbc2 // 50:78:b3:aa:bb:c2
0103 0006 0000 // 0103: MAC 3, 6 bytes
5078 b3aa bbc3 // 50:78:b3:aa:bb:c3
0200 000f 0000 // 0200: Serial Number, 15 bytes
323638454142434445464748494a4b // 268EABCDEFGHIJK
0400 000b 0000 // 0400: BSSID, 11 bytes
4142434445464748494a4b // ABCDEFGHIJK
0510 0010 0000 // 0510: BSSID Password, 16 bytes
4142434445464748494a4b4c4d4e4f50 // ABCDEFGHIJKLMNOP
0701 0008 0000 // 0701: Admin Password, 8 bytes
4142434445464748 // ABCDEFGH
0300 0006 0000 // 0300: Manufacturer MAC, 6 bytes
353037384233 // 5078B3
0806 0006 0000 // 0806: Hardware Revision, 6 bytes
56312e302e31 // V1.0.1
0807 0001 0000 // 0807: Trailer?
30 // "0" ASCII
注意：我已经为MAC / BSSID / Password等使用了伪值！
如果可以找到此文件并执行MD5，其中（例如
md5sum /var/tagparam_m），十六进制摘要的前16个字符是您的密钥。对于一个好的密钥，解密块的前8个字节应类似于
0x0102030400000000，这是ZLIB标头的开头部分。有关此文件格式的更多信息，您可以看一下我编写的zcu模块。
注意：
第二个
tagparam_m文件是字节包装的，但密钥是文件被字节包装后的MD5，后面的00被截断了。 信用：
Dimitris弄清了他的
tagparam_m文件的MD5是关键！@Vido作为第二个示例
tagparam_m文件评论
太好了，我会在有空的时候尽快研究一下。 cspd似乎负责加密和解密多个ZTE设备上的配置，例如此处提到的F660reverseengineering.stackexchange.com/questions/13391/…，但是该方法似乎在不同类型的设备之间有所不同。您可以随时尝试使用quemu运行代码。
– J91321
16-10-24在23:04
我还试图识别备份文件上使用的加密内容，我使用中兴ZXV10 H201L V2，而我的朋友们位于这里reverseengineering.stackexchange.com/questions/14711/…
– Vido
17年1月1日在16:29
我在Speedport Entry 2i上具有shell访问权限和strace以及gdbserver。我未定义按下备份按钮时将调用的进程，因此我可以进一步进行调查并获取备份文件的密码吗？
– Vido
8月30日10:29
@Vido我刚刚根据昨天收到的信息更新了该帖子，如果您可以找到tagparam_m文件，则此文件的MD5应该是您的密钥。
–街道
8月31日11:01
太棒了tnx @streetster
– Vido
8月31日20:30
#2 楼
遇到这些密钥并共享已知的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<vz&f^5'
zxhn h168n hv10_fv310t3_belt - 'GrWM3Hz<vz&f^9'
zxhn h208n hv10_fv1010_belt16t1 - 'Renjx%2$CjM'
zxhn h267n hv10_fv100t3_belt - 'tHG@Ti&GVh@ql3XN'
#3 楼
为了获取密钥，您需要检查CSPDBGetFileEncryKey功能
评论
我没有回答您问题，但这也许可以为您提供帮助。我有同样的问题，我认为我们有相同的加密算法，但密钥不同。这也是我的config.bin，我经常发现数字0x57也许可以决定这些部分。在我的配置文件中是0xb6。也许对您解决它会有所帮助。谢谢，我下载了您的配置，熵看起来与我的非常相似，这是事实。不幸的是，我仍然没有找到有关如何解决此问题的更多信息或想法。
您在这方面是否取得任何进展？我也在从中兴通讯的新家用路由器中查看config.bin。
并非如此，我可能需要获取固件样本并对其进行反向工程，以了解config.bin所发生的情况。但是，如果您愿意分享您的config.bin示例，请看一下。只记得在导出前删除所有机密信息。
@danca您能给我您的Mac地址吗，我认为config的密钥是md5 mac addres