记一次对 DES 加密程序的简单逆向

# 记一次对 DES 加密程序的简单逆向

## 准备

机房电脑中有一个认证程序，看起来很古老了，界面一股 Windows XP 的味道，启动后会占据整个屏幕，并且无法退出。有一次偶然发现程序一个漏洞，通过这个漏洞可以使任意电脑蓝屏，于是就把这个程序拷了回来分析

通过抓包发现，在点击登录按钮后会向 Server 发送一个 UDP 数据包，但是数据并不是明文传输的

尝试了几组用户密码，得到的抓包结果：

| 序号 | 用户 | 密码  | 数据 |
| ---- | ----- | ----- | ------------------------------------------------ |
| 1    | 12345 | 12345 | 3560C2B769749BDAA1349E9A51061CDAD27CAEEA5F6260F6 |
| 2 | 12345 | 54321 | 3560C2B769749BDA6AB016890D61A4F5F3705B2BEE317984 |
| 3 | 12345678 | 12345678 | 3560C2B769749BDAAC682AB9D1E7495466A86348770FA1D605DC514532B96CD5 |
| 4 | 12345678 | 87654321 | 3560C2B769749BDAAC682AB9D1E7495406B94108E79FE90CABDFB974E5906F64 |
| 5 | qwertyuiop | 12345678 | 3560C2B769749BDA2CF15C38C47A73837218656B80E5BE2B29288CA2C9ABD8AD |
| 6 | 999999999999999999 | 999999999999999 | 3560C2B769749BDAC347844BD93FE1C8C347844BD93FE1C8CED86E088CF458ADC347844BD93FE1C84463ABE3D4B83B20 |

可以很明显地观察到

1. 每组数据都有以一串相同的数据 `3560C2B769749BDA` 开头，猜测是作为头部信息向 Server 描述这个 Packet 的功能意图是登录用户。
2. 观察 3 号数据包和 4 号数据包发现，如果用户名较长，在用户名不变的情况下，改变密码只会使部分数据变动，而 1 和 2 中没有这一特点
3. 每一组数据长度都是 8 的整数倍

根据这 3 点可以不难猜出加密采用的对称加密，分组模式，每组为 8 字节。根据这些特点可以大胆的猜测使用了 DES 加密

## 逆向

拖到 IDA，因为程序不大，首先从 String 入手，很快就注意到了几个可疑的 String：

![image-20240408165058067](https://0x1.ink/usr/uploads/2024/04/1349220918.png)

不过这些应该都不是密钥，如果是 DES 加密，密钥应该是 8 个字符才对，但是找了一会也没找到符合要求的密钥，所以从最可疑字符串开始一个个跟进去。

从最可疑的 `CODE:004DDE24` 跟进去，一看这个差点劝退我：

![image-20240408170514146](https://0x1.ink/usr/uploads/2024/04/1377759804.png)

好在很快就找到了 `sub_4D96D8` 中的一处代码，经过某种判断逻辑后，执行了同目录下的 `mypro.exe`。通过之前的分析可知，在登录成功后就会执行这个程序，经过简单分析很快发现该语句块用于离开登录屏幕并解锁桌面等一大堆操作，在用户验证成功后执行，看来这个函数就是处理登陆界面逻辑的了。

```c
     if ( v9 )                                 // //离开登陆界面
      {
        sub_4D44A0((int)"mypro.exe");
        sub_435470(a1[222], 0);
        sub_435470(a1[232], 0);
        sub_435470(a1[264], 0);
        sub_4D8510(ExceptionList, v15, v16);
        sub_46113C(v10);
        sub_4BDAB0();
        sub_4BDA9C();
        sub_4BDA4C();
        sub_4BDE2C(10, 1);
        ClipCursor(0);
        sub_4D7D50();
        sub_4569B8();
        sub_435480(a1[241], 30000);
        goto LABEL_12;
      }
      sub_444B64(&v21, a1[196]);
      sub_404E60(ExceptionList, v15, v16);
      if ( v9 )
      {
        sub_4D44A0((int)"mypro.exe");
        byte_4E6A40 = 1;
        sub_460F9C(ExceptionList, v15, v16);
      }
```

很快定位到执行发送数据包逻辑的函数是附近的一段 if 语句，在最后一步通过一个看起来很复杂的调用实现的数据传输（应该是系统的某个 API），现在可以开始分析加密过程了：

```c
      sub_4D89E8(ExceptionList);
      sub_47A01C();
      sub_435470(a1[0xDE], 1);
      v11 = a1[0xE2];
      if ( *(_BYTE *)(v11 + 0x4EA) != 8 )
      {
        sub_444B64(&v18, a1[0xC3]);             // 获取用户名的值放到v21
        sub_444B64(&v17, a1[0xC4]);             // 获取密码的值放到v20
        sub_404DD4(&v19, 4);                    // 拼接用户名和密码，使用#分割，格式为/*....*/用户#密码
        sub_4BFA2C((int *)v19, dword_4D9B20, &v20);
        (*(void (**)(void))(*(_DWORD *)v11 + 244))();
      }
```

通过分析函数代码，在 `sub_404DD4` 一通操作后，用户名和密码会被格式化为 `/\*\xB5\xC7\xC2\xBD\*/用户#密码` 的格式，`#` 是分隔符，前面的内容看起来像是注释语法，`\xB5\xC7\xC2\xBD` 不知道是个什么东西，然后调用了 `sub_4BFA2C` 进行加密。所以 `2F2AB5C7C2BD2A2F` 对应的就是密文中总是固定的 `3560C2B769749BDA`，到这里已经知道一组明文和对应密文了，假设 `sub_4BFA2C` 中没有对明文进行修改，那现在其实可以尝试暴力破解了。

![image-20240408173041636](https://0x1.ink/usr/uploads/2024/04/3769199016.png)

继续分析，函数 `sub_4BFA2C` 传入了 3 个参数，分别是原始内容地址，`dword_4D9B20`，结果地址。`dword_4D9B20` 应该是存储了密钥

不过查看该处数据，发现数据有些奇怪，数据不仅很长还包含了非打印字符，只好继续跟进去

![image-20240408174311604](https://0x1.ink/usr/uploads/2024/04/871376320.png)

跟进 `sub_4BFA2C`，发现实际上是将参数丢给 `sub_4BF6B4` 进行加密的：

```c
int *__usercall sub_4BFA2C@<eax>(int *_origin_str@<eax>, char *a2@<edx>, volatile __int32 *a3@<ecx>)
{
  int result_addr; // [esp+18h] [ebp-10h] BYREF
  char *key; // [esp+20h] [ebp-8h]
  char *origin_str; // [esp+24h] [ebp-4h]
  result_addr = 0;
  key = a2;
  origin_str = (char *)_origin_str;
  sub_404F04(_origin_str);
  sub_404F04((int *)key);

sub_4BF6B4(origin_str, key, &result_addr);
  //...
}
```

`sub_4BF6B4` 定义如下：

```c
int *__usercall sub_4BF6B4@<eax>(char *_origin_str@<eax>, char *_key@<edx>, int *_result_addr@<ecx>)
{
  int v3; // eax
  char *v4; // edx
  int v5; // eax
  int v6; // ebx
  int *v7; // eax
  int v8; // eax
  int v9; // ebx
  char *v10; // eax
  int v11; // ebx
  char *v12; // esi
  unsigned int v14[2]; // [esp-Ch] [ebp-48h] BYREF
  int *v15; // [esp-4h] [ebp-40h]
  char *v16; // [esp+8h] [ebp-34h] BYREF
  int v17; // [esp+Ch] [ebp-30h]
  int v18; // [esp+10h] [ebp-2Ch]
  char *v19; // [esp+14h] [ebp-28h] BYREF
  int v20[2]; // [esp+18h] [ebp-24h] BYREF
  char v21[8]; // [esp+20h] [ebp-1Ch] BYREF
  char v22[8]; // [esp+28h] [ebp-14h] BYREF
  volatile __int32 *result_addr; // [esp+30h] [ebp-Ch]
  char *key; // [esp+34h] [ebp-8h] BYREF
  char *origin_str; // [esp+38h] [ebp-4h] BYREF
  int savedregs; // [esp+3Ch] [ebp+0h] BYREF

v16 = 0;
  v19 = 0;
  result_addr = _result_addr;
  key = _key;
  origin_str = _origin_str;
  sub_404F04((int *)_origin_str);
  sub_404F04((int *)key);
  v15 = &savedregs;
  v14[1] = (unsigned int)&loc_4BF851;
  v14[0] = (unsigned int)NtCurrentTeb()->NtTib.ExceptionList;
  __writefsdword(0, (unsigned int)v14);
  if ( sub_404D14((int)origin_str) > 0 )
  {
    v3 = sub_404D14((int)origin_str);
    v4 = origin_str;
    if ( !origin_str[v3 - 1] )
    {
      LOBYTE(v4) = 1;
      v5 = sub_40CD18("Error: the last char is NULL char.", v4);
      sub_40444C(v5);
    }
  }
  if ( sub_404D14((int)key) < 8 )
  {
    while ( sub_404D14((int)key) < 8 )
      sub_404D1C(&key, (char *)&dword_4BF894);
  }
  while ( sub_404D14((int)origin_str) % 8 )
    sub_404D1C(&origin_str, (char *)&dword_4BF894);
  v6 = 0;
  v7 = v20;
  do
  {
    *(_BYTE *)v7 = key[v6++];
    v7 = (int *)((char *)v7 + 1);
  }
  while ( v6 != 8 );
  sub_4BF284(v20, 7, (int)&unk_4FC850, 15);
  sub_404A54(&v19);
  v8 = sub_404D14((int)origin_str) / 8 - 1;
  if ( v8 >= 0 )
  {
    v17 = v8 + 1;
    v18 = 0;
    do
    {
      v9 = 0;
      v10 = v22;
      do
        *v10++ = origin_str[8 * v18 + v9++];
      while ( v9 != 8 );
      sub_4BF4DC(0, v22, 7, 7, v21);
      v11 = 8;
      v12 = v21;
      do
      {
        sub_404C3C((int **)&v16);
        sub_404D1C(&v19, v16);
        ++v12;
        --v11;
      }
      while ( v11 );
      ++v18;
      --v17;
    }
    while ( v17 );
  }
  sub_404AA8(result_addr, (__int32)v19);
  __writefsdword(0, v14[0]);
  v15 = (int *)&loc_4BF858;
  sub_404A54(&v16);
  sub_404A54(&v19);
  return sub_404A78((int *)&key, 2);
}
```

通过上面的详细分析，前面都是各种数据检验，检查 `origin_str` 是否为空，检查 key 长度是否为 8 的倍数，如果不满足则调用 `sub_404D1C`，实际传入的数据满足这些逻辑，因此并没有改变源数据

一直到第 56 行，通过一个循环将 key 数据的前 8 个字节复制到了 v20，然后传递给 `sub_4BF284` 函数:

```c
int __userpurge sub_4BF284@<eax>(int *a1@<eax>, int a2@<edx>, int a3@<ecx>, int a4)
{
  signed int v4; // ebx
  int v5; // esi
  int v6; // ecx
  int v7; // edi
  _BYTE *v8; // ebx
  int v9; // esi
  int v10; // ecx
  int result; // eax
  int v12; // [esp-4h] [ebp-2Ch] BYREF
  char v13; // [esp+Eh] [ebp-1Ah]
  char v14; // [esp+Fh] [ebp-19h]
  char v15; // [esp+10h] [ebp-18h]
  char v16; // [esp+11h] [ebp-17h]
  char v17; // [esp+12h] [ebp-16h]
  char v18; // [esp+13h] [ebp-15h]
  char v19; // [esp+14h] [ebp-14h]
  char v20; // [esp+15h] [ebp-13h] BYREF
  char v21; // [esp+16h] [ebp-12h]
  char v22; // [esp+17h] [ebp-11h]
  char v23; // [esp+18h] [ebp-10h]
  char v24; // [esp+19h] [ebp-Fh] BYREF
  unsigned __int8 v25; // [esp+1Ah] [ebp-Eh]
  unsigned __int8 v26; // [esp+1Bh] [ebp-Dh]
  unsigned __int8 v27; // [esp+1Ch] [ebp-Ch]
  unsigned __int8 v28; // [esp+1Dh] [ebp-Bh] BYREF
  unsigned __int8 v29; // [esp+1Eh] [ebp-Ah]
  unsigned __int8 v30; // [esp+1Fh] [ebp-9h]
  unsigned __int8 v31; // [esp+20h] [ebp-8h]
  char v32; // [esp+21h] [ebp-7h]
  char v33; // [esp+22h] [ebp-6h]
  char v34; // [esp+23h] [ebp-5h]

if ( a2 >= 0 )
  {
    v4 = (unsigned int)a2 >> 2;
    do
    {
      v5 = a1[v4--];
      v12 = v5;
    }
    while ( v4 >= 0 );
  }
  sub_4BF0F4((int)&v12, a2, (int)&v28, 6);
  v24 = v28 >> 4;
  v25 = (v29 >> 4) | (16 * v28);
  v26 = (v30 >> 4) | (16 * v29);
  v6 = v31 >> 4;
  v27 = v6 | (16 * v30);
  v20 = v31 & 0xF;
  v21 = v32;
  v22 = v33;
  v23 = v34;
  v7 = 16;
  v8 = &unk_4E3DAC;
  v9 = a3;
  do
  {
    LOBYTE(v6) = *v8;
    sub_4BF224(&v24, v6);
    LOBYTE(v10) = *v8;
    sub_4BF224(&v20, v10);
    v13 = (v25 >> 4) | (16 * v24);
    v14 = (v26 >> 4) | (16 * v25);
    v15 = (v27 >> 4) | (16 * v26);
    v16 = v20 | (16 * v27);
    v17 = v21;
    v18 = v22;
    v19 = v23;
    result = sub_4BF18C(5);
    v9 += 6;
    ++v8;
    --v7;
  }
  while ( v7 );
  return result;
}
```

`sub_4BF284` 中有一堆引入注目的移位操作，并且还进行了 16 次。还有一处反编译器没分析出来的 CODE 数据地址 `unk_4E3DAC`，打开：

```asm
DATA:004E3DAC unk_4E3DAC      db    1                 ; DATA XREF: sub_4BF284+89↑o
DATA:004E3DAD                 db    1
DATA:004E3DAE                 db    2
DATA:004E3DAF                 db    2
DATA:004E3DB0                 db    2
DATA:004E3DB1                 db    2
DATA:004E3DB2                 db    2
DATA:004E3DB3                 db    2
DATA:004E3DB4                 db    1
DATA:004E3DB5                 db    2
DATA:004E3DB6                 db    2
DATA:004E3DB7                 db    2
DATA:004E3DB8                 db    2
DATA:004E3DB9                 db    2
DATA:004E3DBA                 db    2
DATA:004E3DBB                 db    1
```

这不就是 DES 生成子密钥算法中的循环左移位数嘛，改名，转为 byte 数组。

再往前面翻一翻，附近两个未解析的数据，也是在一看原来是 PC_1 和 PC_2，在 `sub_4BF0F4` 和 `sub_4BF18C` 被使用：

```asm
DATA:004E3D44 PC1             db 38h, 30h, 28h, 20h, 18h, 10h, 8, 0, 39h, 31h, 29h, 21h
DATA:004E3D44                                         ; DATA XREF: sub_4BF0F4+31↑o
DATA:004E3D50                 db 19h, 11h, 9, 1, 3Ah, 32h, 2Ah, 22h, 1Ah, 12h, 0Ah, 2
DATA:004E3D5C                 db 3Bh, 33h, 2Bh, 23h, 3Eh, 36h, 2Eh, 26h, 1Eh, 16h, 0Eh
DATA:004E3D67                 db 6, 3Dh, 35h, 2Dh, 25h, 1Dh, 15h, 0Dh, 5, 3Ch, 34h, 2Ch
DATA:004E3D73                 db 24h, 1Ch, 14h, 0Ch, 4, 1Bh, 13h, 0Bh, 3
DATA:004E3D7C PC2             db 0Dh, 10h, 0Ah, 17h, 0, 4, 2, 1Bh, 0Eh, 5, 14h, 9, 16h
DATA:004E3D7C                                         ; DATA XREF: sub_4BF18C+31↑o
DATA:004E3D89                 db 12h, 0Bh, 3, 19h, 7, 0Fh, 6, 1Ah, 13h, 0Ch, 1, 28h
DATA:004E3D95                 db 33h, 1Eh, 24h, 2Eh, 36h, 1Dh, 27h, 32h, 2Ch, 20h, 2Fh
DATA:004E3DA0                 db 2Bh, 30h, 26h, 37h, 21h, 34h, 2Dh, 29h, 31h, 23h, 1Ch
DATA:004E3DAB                 db 1Fh
DATA:004E3DAC shiftTable      db 1, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1
```

现在就很清晰了，`sub_4BF284` 函数是用来生成子密钥的，先使用 `sub_4BF0F4` 进行 PC1 置换，然后进行 16 次迭代移位操作和 `sub_4BF18C` 的 PC2 置换。所以，尽管 `dword_4D9B20` 处的密钥数据很长，实际上只会复制前 8 个字节内容，因此真正的密钥就是 `dword_4D9B20` 处的前 8 个字节 `435379A3BB313139`

试着解密，果然正确

![image-20240408191340137](https://0x1.ink/usr/uploads/2024/04/1768318180.png)

一直一个奇怪的地方，为什么密钥中会有两个字节的非可打印字符。然后突然想到了会不会是中文汉字，GBK 编码就是 2 字节的，一查还真有，是分号：

![image-20240408191540983](https://0x1.ink/usr/uploads/2024/04/3967843234.png)

于是联想到密文中的四个字节，一看，居然是 `登陆` 这两个汉字：

![image-20240408191750744](https://0x1.ink/usr/uploads/2024/04/1346002467.png)

`sub_4BF6B4` 的完整分析：

v16 = 0;
  v19 = 0;
  result_addr = _result_addr;
  key = _key;                                   // dword_4D9B20, key
  origin_str = _origin_str;                     // 待加密数据
  sub_404F04((int *)_origin_str);
  sub_404F04((int *)key);
  v15 = &savedregs;
  v14[1] = (unsigned int)&loc_4BF851;
  v14[0] = (unsigned int)NtCurrentTeb()->NtTib.ExceptionList;
  __writefsdword(0, (unsigned int)v14);
  // 输入验证
  if ( sub_404D14((int)origin_str) > 0 )        // 检测origin_str长度是否非空
  {
    v3 = sub_404D14((int)origin_str);
    v4 = origin_str;
    if ( !origin_str[v3 - 1] )                  // 检测origin_str最后一个字符是否为NULL
                                                // 若为NULL则抛出异常
    {
      LOBYTE(v4) = 1;
      v5 = sub_40CD18("Error: the last char is NULL char.", v4);
      sub_40444C(v5);
    }
  }
  if ( sub_404D14((int)key) < 8 )               // 检测key长度（实际固定为16字节，因此不会进入）
  {
    while ( sub_404D14((int)key) < 8 )
      sub_404D1C(&key, (char *)&dword_4BF894);  // 猜测是循环填充使其满足条件
  }
  while ( sub_404D14((int)origin_str) % 8 )     // 检测key长度是否为8的倍数
    sub_404D1C(&origin_str, (char *)&dword_4BF894);// 猜测是循环填充使其满足条件
  // 密钥准备
  v6 = 0;
  v7 = v20;
  do
  {
    *(_BYTE *)v7 = key[v6++];                   // 从key复制8个字节数据到v20
    v7 = (int *)((char *)v7 + 1);
  }
  while ( v6 != 8 );
  sub_4BF284(v20, 7, (int)&unk_4FC850, 15);
  sub_404A54(&v19);
  // 开始加密
  v8 = sub_404D14((int)origin_str) / 8 - 1;     // 确定需要处理的块数，每个块为8字节
  if ( v8 >= 0 )
  {
    v17 = v8 + 1;                               // 实际块数
    v18 = 0;
    do
    {
      v9 = 0;
      v10 = v22;
      do
        *v10++ = origin_str[8 * v18 + v9++];    // 将原始数据中的一个块复制到v22
      while ( v9 != 8 );
      sub_4BF4DC(0, v22, 7, 7, v21);            // 加密数据，v22为原始数据块，v21存储加密结果
      // 第一块中总是产生固定的结果
      // 3560C2B769749BDA
      // 并将其放置在栈上，稍后将其存储到地址v19（追加）
      v11 = 8;
      v12 = v21;
      do
      {
        sub_404C3C((int **)&v16);
        sub_404D1C(&v19, v16);                  // 将v16数据追加到v19，v19处存储最终加密结果
        ++v12;
        --v11;
      }
      while ( v11 );
      ++v18;
      --v17;
    }
    while ( v17 );
  }
  sub_404AA8(result_addr, (__int32)v19);
  __writefsdword(0, v14[0]);
  v15 = (int *)&loc_4BF858;
  sub_404A54(&v16);
  sub_404A54(&v19);
  return sub_404A78((int *)&key, 2);
}
```

## 暴力破解

前文提到可以进行暴力破解，这里小记一下：

可以使用 `hashcat` 进行快速的破解：

```shell
hashcat --self-test-disable --keep-guessing -a 3 -m 14000 '3560C2B769749BDA:2F2AB5C7C2BD2A2F' -1 .\charsets\DES_full.hcchr --hex-charset '435379A3?1?1?1?1'
```

`-a 3` 指定使用掩码破解

`-m 14000` 对应 DES 加密

`'3560C2B769749BDA:2F2AB5C7C2BD2A2F'` 16 字节密文: 16 字节明文

`-1 .\charsets\DES_full.hcchr` 用于指定 charset, 因为后面的掩码直接使用了 HEX 明文

`--hex-charset '435379A3?1?1?1?1'` 掩码攻击，这里指定了前 4 个字节（因为已经知道了密钥，这里我就假装前 4 个字节是已知的。如果密钥都是未知的，那其实可能很慢，除去校验位还有 56 个位要一个个跑）

`hashcat` 跑出了一个密钥: `435379a3ba313138`，和逆向出来的密钥不同是因为校验位的差异，目前这个版本（v6.2.6）的 `hashcat` 不会输出所有可能的结果

```shell
> hashcat --self-test-disable --keep-guessing -a 3 -m 14000 '3560C2B769749BDA:2F2AB5C7C2BD2A2F' -1 .\charsets\DES_full.hcchr --hex-charset '435379A3?1?1?1?1'
Session..........: hashcat
Status...........: Running
Hash.Mode........: 14000 (DES (PT = $salt, key = $pass))
Hash.Target......: 3560c2b769749bda:2f2ab5c7c2bd2a2f
Time.Started.....: Mon Apr 08 19:53:40 2024 (4 secs)
Time.Estimated...: Mon Apr 08 19:53:50 2024 (6 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: 435379A3?1?1?1?1 [8]
Guess.Charset....: -1 charsets/DES_full.hcchr, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  5101.6 kH/s (0.48ms) @ Accel:4 Loops:1024 Thr:256 Vec:1
Speed.#3.........: 20735.2 kH/s (0.39ms) @ Accel:64 Loops:1024 Thr:64 Vec:1
Speed.#*.........: 25836.7 kH/s
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 93696000/268435456 (34.90%)
Rejected.........: 0/93696000 (0.00%)
Restore.Point....: 93564928/268435456 (34.86%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1024
Restore.Sub.#3...: Salt:0 Amplifier:0-1 Iteration:0-1024
Candidate.Engine.: Device Generator
Candidates.#1....: $HEX[435379a361c1a858] -> $HEX[435379a3fe9eab57]
Candidates.#3....: $HEX[435379a361a1b557] -> $HEX[435379a3fe9eb654]
Hardware.Mon.#1..: Temp: 49c Util: 96% Core: 210MHz Mem: 405MHz Bus:8
Hardware.Mon.#3..: N/A

3560c2b769749bda:2f2ab5c7c2bd2a2f:$HEX[435379a3ba313138]

[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit =>
```

本文由 CloverGit 发表
本站文章未注明出处均为本站原创
采用知识共享署名-相同方式共享 4.0 (CC BY 4.0) 国际许可协议进行许可
转载时务必遵守许可协议进行署名
最后编辑于: 2024 年 4 月 29 日 09 时 31 分