欺诈式数据库连接

2026-06-22 in 技术记录 lang 繁 read (80)

这也是几个月之前的事儿了，但说无妨了。
当时的情况是一个客户找到我，大致意思是说想换服务器。
换服务器这事儿可大可小，但偏偏他们的软件开发不想他们换。

检查过后，发现了原因，这是一个C#语言开发的网站程序。
多数文件直接打包迁移就好，包括数据库也是。
难点在于网站的配置文件属于部分加密的。

是的，不是全篇加密，是只有数据库连接串加密。
更具体的说，还不是整个数据库连接串加密，是部分连接串加密。
我大概能猜到数据库连接串的写法，所以我试图明文写这部分。
但是程序是强制解密的，对于我的明文，依旧会正常解密。

那就只能尝试解密，看看数据库连接串里到底写了什么喽。
按照解密失败的报错，找到相应的.dll文件。
用一个叫dnSpy的程序可以逆向解密C#编译的.dll文件。
果不其然，我找到了加密的密钥。

但难题又来了，我不太懂C#，我最熟悉的一直都是php。
这意味着，即便拿到密钥，我也仍然是解不开的。

这个时候当然是请出千问老师和豆包老师了。
最后是千问先拔头筹，给了我解决办法，千问给我写了这样的代码：

from Crypto.Cipher import DES3
from Crypto.Util.Padding import unpad
import hashlib
import base64

# 1. 准备数据
ciphertext_base64 = "【加密的数据库连接串】"
password = "【.dll文件里找到的密钥】"

# 2. 核心逻辑：还原 C# 的 Key 生成方式
# 先对密码做 MD5 (得到 16 字节)
md5_hash = hashlib.md5(password.encode('utf-8')).digest()
# 为了凑齐 24 字节，将 MD5 结果重复拼接 (16字节 + 前8字节 = 24字节)
# 这是 C# 3DES 最常见的 Key 补齐方式
key = md5_hash + md5_hash[:8]

# 3. 解密
# 初始化 Cipher，模式 ECB，填充 PKCS7 (在 pycrypto 中对应 PKCS7)
cipher = DES3.new(key, DES3.MODE_ECB)
ciphertext = base64.b64decode(ciphertext_base64)

# 解密并去填充
try:
    decrypted_padded = cipher.decrypt(ciphertext)
    # 尝试使用 PKCS7 去填充
    decrypted = unpad(decrypted_padded, DES3.block_size, style='pkcs7')
    print("解密成功 (PKCS7):")
    print(decrypted.decode('utf-8'))
except ValueError:
    # 如果 PKCS7 失败，尝试 NoPadding (有些旧程序不填充)
    print("PKCS7 失败，尝试原始数据:")
    print(decrypted_padded)

这明显是一段Python代码，那么难题又来了，我对Python也不熟悉。
然后我就发现了有个东西叫Python在线工具，直接贴进去代码，点一下运行就得到了数据库连接串。
有意思的是，原始的数据库连接串朴实无华，没有任何特殊处理，和我写的一样。

我把数据库地址、用户名、密码和库名改过之后，新问题又来了。
我试图让千问和豆包按照密钥给我加密回去，加密了几次都是失败的。
通过报错，发现加密程序是在开发公司的电脑的F盘里，这个我说什么也拿不到。
这个时候就得用点儿AI永远无法替代人类的办法了。

我干脆删库、删用户名，重新建库。
新建库和用户名，和原本的一摸一样。
然后，我打开了服务器的hosts文件，把原来的数据库地址强制解析到127.0.0.1。
这样，即使访问原来的数据库地址，访问的也是本地数据库！
我选择对程序进行了一次服务器内部的欺诈。
安全层面上讲，这个算是DNS劫持了。

测试网站访问正常，客户原服务器关机，测试访问仍然正常，迁移完成。

其实数据迁移不是什么难题，甚至是我最擅长的领域。
而修改hosts也是常见操作，很多时候做测试都会用到。
只不过这次是遇到了我最不熟悉的C#，还是加密，开发公司又不配合。
两个办法加一起，就是1+1>2的经典案例了。

过去的数年里，我一直很回避在自己的网站里写技术内容，两个原因：
1.我不觉得自己的水平很强，偶尔的灵光一闪也都是将两种常见操作组合，显得出其不意而已。
2.我一直将自己的网站定位成自己生活的记录，而非工作记录。

然而现在的情况就是，早年我差不多一年时间处理的服务器问题起码500多个。
这种工作强度下，记不记录不重要，孰能生巧，没什么不会的。
而现在，基本上找到我的都是稍微复杂一点点的问题，且基本上都是孤例。
这意味着，不记录的话，也许回头我就给忘记了。

再者，现在工作和生活也没有明确的界限了。
以前给别人打工，现在公司是自己的，很多时候工作和生活的边界就是很模糊的。
甚至，我当年基本上不用家里的台式机工作，我给家里电脑的定位就是打游戏用的。
而现在很多时候就是在家里工作，界限早就模糊了。

所以移除了网站的读书笔记分类，新增了技术记录分类。
毕竟现在遇到难题的情况远超过我看书的速度，我现在就不看书。