1. 为什么我们需要了解Navicat连接文件你可能和我一样是个经常和数据库打交道的开发者或者运维。每天开电脑第一件事就是打开Navicat连上服务器开始一天的工作。Navicat确实方便把那些复杂的连接参数——主机地址、端口、用户名、密码——都帮你存好了下次一点就通。但你想过没有这些敏感信息特别是数据库密码Navicat到底是怎么存的是明文吗还是加密了如果加密了安不安全我遇到过好几次这样的场景。有一次团队里负责某个项目的同事突然离职交接文档里只提到了服务器IP数据库密码没留下。我们只知道他用Navicat连过但电脑已经交还了。还有一次公司做安全审计要求梳理所有数据库的访问凭证一个个去问开发同事密码效率低不说还容易出错。更常见的是我自己换了台新电脑想把旧电脑上的几十个数据库连接迁移过来难道要一个个重新输入密码这时候如果你知道Navicat其实提供了一个“导出连接”的功能能把所有连接配置保存成一个.ncx文件问题似乎就解决了一半。你可以把这个文件拷贝到新电脑上再“导入连接”。但关键是这个.ncx文件里密码是直接能看到的吗如果看不到我们有没有办法把它“读”出来这就是我们今天要聊的核心逆向分析Navicat的.ncx连接文件找到并解密其中存储的数据库密码。这个过程本质上是一次小小的“安全研究”或“数据恢复”。它不是为了攻击而是为了在合法、合理的场景下比如密码遗忘、配置迁移、安全审计恢复我们本应拥有但暂时无法直接获取的信息。理解了这个你不仅能解决实际问题还能对软件如何存储敏感信息有更深的认知。接下来我就带你一步步拆解这个.ncx文件看看Navicat到底把我们的密码藏在了哪里以及我们如何用几行代码把它“请”出来。2. 初探Navicat连接文件从导出到文件结构首先我们得拿到这个关键的.ncx文件。操作很简单打开你的Navicat我用的Navicat Premium 15但理论上12以上版本都差不多在顶部菜单栏找到“文件” - “导出连接”。这时候会弹出一个对话框让你选择要导出哪些连接。你可以全选也可以只选几个。关键一步来了务必勾选“导出密码”。如果不勾选导出的文件里密码字段就是空的我们后续操作也就没意义了。选好保存路径比如桌面文件名就用默认的connections.ncx点击确定。现在你的桌面上应该多了一个connections.ncx文件。用记事本或者任何文本编辑器比如VS Code、Sublime Text打开它。你会看到一堆像下面这样的内容?xml version1.0 encodingUTF-8? Connections Connection ConnectionName我的生产数据库 ConnTypeMYSQL Host192.168.1.100 Port3306 UserNameadmin PasswordU2FsdGVkX1abc123...很长一串... Databaseapp_db ... / Connection ConnectionName测试环境 ConnTypeMYSQL Hosttest.db.com Port3306 UserNametester PasswordU2FsdGVkX1def456...另一串... Databasetest_db ... / ... /Connections没错.ncx文件本质上就是一个XML文件。XML是一种结构化的标记语言非常适合用来存储配置信息。根节点是Connections里面每个Connection节点就代表你在Navicat里保存的一个数据库连接。一眼扫过去ConnectionName连接名、ConnType数据库类型如MySQL、PostgreSQL、Host主机地址、Port端口、UserName用户名、Database数据库名都是明文存储的一目了然。但是Password字段看起来是一大串乱七八糟的字符像U2FsdGVkX1开头后面跟着Base64编码似的字符串。这显然不是我们设置的原始密码“123456”或者“Admin2024”它被加密了。所以我们现在清楚了Navicat导出连接时除了密码其他信息都是明文存储。密码经过了某种加密处理。我们的目标就是破解这个加密还原出明文密码。接下来我们需要搞清楚它用的是哪种加密算法。3. 逆向关键Navicat使用了哪种加密方式面对一串加密的字符串我们首先要判断它的加密算法。根据网络上众多开发者逆向分析的结果包括参考一些技术社区的文章可以确定Navicat在.ncx文件中使用的密码加密方式是AES。AES高级加密标准是一种对称加密算法也就是加密和解密用的是同一把钥匙。这很合理因为Navicat需要在本地解密密码来连接数据库它必须把“钥匙”也放在某个地方或者使用一个固定的、内置的钥匙。那么具体是AES的哪种模式呢常见的AES模式有ECB、CBC等。从加密字符串的格式和逆向代码来看Navicat使用的是AES-256-CBC模式。这里简单解释一下AES-256表示密钥长度是256位算是AES里强度很高的了。CBC模式密码分组链接模式。这种模式需要一个“初始化向量”来增加安全性防止相同的明文加密后得到相同的密文。光知道算法和模式还不够我们还需要两个关键参数密钥用来加密和解密的那把“钥匙”。初始化向量CBC模式必需的一个随机或固定的值。经过逆向工程分析Navicat在这里使用了一组硬编码的、固定的值作为密钥和IV。也就是说无论你在哪台电脑上用哪个版本的Navicat在一定版本范围内它加密密码时用的钥匙和IV都是一样的。这听起来似乎降低了安全性但它的目的可能只是为了防止密码在配置文件里一眼被看穿而不是防御有意的、深入的破解。这组固定的值是密钥libcckeylibcckey注意长度正好是16个字符即128位等等AES-256需要32字节密钥。这里是个线索我们后面会看到实际处理。初始化向量libcciv libcciv注意末尾有个空格一共16个字符看到这里你可能有点疑惑libcckeylibcckey这长度也不像32字节啊别急在具体的代码实现中Navicat很可能对这个字符串进行了处理比如直接取其UTF-8字节或者重复拼接来生成最终的256位密钥。我们在写解密代码时需要按照它的方式来。另外还有一个细节加密后的密文在存储前还进行了一次Base64编码。所以我们从XML文件的Password属性里拿到的那串“乱码”其实是经过AES-256-CBC加密后再经过Base64编码的结果。解密过程就需要反过来先Base64解码再用AES解密。4. 实战手把手编写Java解密程序理论清楚了我们来点实际的。我将用一个Java程序来演示整个解密过程。为什么用Java因为相关库很成熟代码清晰而且很多后端开发者也熟悉。我会选用一个非常棒的国产工具库——Hutool它封装了很多常用功能让代码变得极其简洁。当然我们还需要dom4j来解析XML。首先创建一个Maven项目在pom.xml里添加依赖dependencies !-- Hutool全能工具库 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.3/version /dependency !-- 解析XML文件 -- dependency groupIdorg.dom4j/groupId artifactIddom4j/artifactId version2.1.3/version /dependency !-- Bouncy Castle加密库用于支持PKCS7Padding -- dependency groupIdorg.bouncycastle/groupId artifactIdbcprov-jdk15to18/artifactId version1.68/version /dependency /dependencies这里特别说明一下Bouncy Castle这个库。AES加密时需要指定一个“填充模式”Navicat使用的是PKCS7Padding。但是Java标准库自带的JCEJava密码学扩展默认不支持PKCS7Padding只支持PKCS5Padding。在AES块加密的上下文中PKCS5Padding和PKCS7Padding在算法上其实是等价的但为了完全匹配Navicat的实现避免任何意外我们引入Bouncy Castle这个强大的第三方加密库来提供PKCS7Padding的支持。依赖搞定后我们开始写核心的解密类NavicatPasswordimport cn.hutool.core.io.file.FileReader; import cn.hutool.crypto.symmetric.AES; import org.dom4j.Document; import org.dom4j.DocumentHelper; import org.dom4j.Element; import org.dom4j.Attribute; import java.util.Iterator; public class NavicatPassword { public static void main(String[] args) throws Exception { // 第一步读取导出的.ncx文件 // 请把这里的路径换成你实际存放connections.ncx文件的路径 FileReader fileReader new FileReader(C:\\Users\\你的用户名\\Desktop\\connections.ncx); String xmlContent fileReader.readString(); System.out.println( 原始XML内容 ); System.out.println(xmlContent); // 可以看一眼原始结构 // 第二步使用dom4j解析XML Document document DocumentHelper.parseText(xmlContent); Element root document.getRootElement(); // 获取Connections根节点 // 假设我们处理第一个连接你可以遍历处理所有Connection Element firstConnection root.elementIterator(Connection).next(); // 第三步提取连接属性这些是明文的 String connectionName firstConnection.attributeValue(ConnectionName); String connType firstConnection.attributeValue(ConnType); String host firstConnection.attributeValue(Host); String port firstConnection.attributeValue(Port); String userName firstConnection.attributeValue(UserName); String encryPassword firstConnection.attributeValue(Password); // 这是加密的密码 String database firstConnection.attributeValue(Database); System.out.println(\n 连接信息解析 ); System.out.println(1. 连接名称: connectionName); System.out.println(2. 数据库类型: connType); System.out.println(3. 主机(IP): host); System.out.println(4. 端口: port); System.out.println(5. 用户名: userName); System.out.println(7. 数据库名称: database); // 第四步核心解密部分 System.out.println(\n 开始解密密码 ); System.out.println(加密后的密码字符串: encryPassword); // 初始化AES解密器 // 参数说明 // 模式: CBC // 填充: PKCS7Padding (需要BouncyCastle支持) // 密钥: libcckeylibcckey.getBytes() - 注意Hutool内部可能会处理密钥长度 // 初始化向量: libcciv libcciv .getBytes() AES aes new AES(CBC, PKCS7Padding, libcckeylibcckey.getBytes(), libcciv libcciv .getBytes()); // 解密Hutool的decryptStr方法会自动处理Base64解码 String plainPassword aes.decryptStr(encryPassword); System.out.println(6. 解密后的密码: plainPassword); System.out.println(\n); // 第五步打印该连接的所有属性可选 System.out.println( 该连接全部属性 ); IteratorAttribute attrIter firstConnection.attributeIterator(); while (attrIter.hasNext()) { Attribute attr attrIter.next(); System.out.println(attr.getName() : attr.getValue()); } } }把上面代码中的文件路径修改成你电脑上connections.ncx的实际位置然后运行这个Java程序。如果一切顺利你会在控制台看到类似这样的输出 连接信息解析 1. 连接名称: 我的生产数据库 2. 数据库类型: MYSQL 3. 主机(IP): 192.168.1.100 4. 端口: 3306 5. 用户名: admin 7. 数据库名称: app_db 开始解密密码 加密后的密码字符串: U2FsdGVkX19abc123...密文 6. 解密后的密码: MySecretDBPassword123!看到了吗那个看似杂乱无章的加密字符串被我们成功还原成了你当初设置的明文密码这个过程是不是比想象中简单Hutool库帮我们隐藏了Base64解码、AES解密模式设置等细节让核心代码非常清晰。5. 深入原理解密过程的技术细节拆解虽然上面的代码跑通了但作为一个爱折腾的技术人我们不能满足于“能用”还得知道“为什么能用”。我们来把Hutool那一行aes.decryptStr(encryPassword)背后发生的事情掰开揉碎讲一讲。首先我们从XML中取到的encryPassword字符串例如U2FsdGVkX1...它并不是直接的AES密文。仔细观察开头U2FsdGVkX1这是经过OpenSSL格式的Salted标识。实际上Navicat的加密过程可能与OpenSSL的enc命令采用了一种兼容的格式。这种格式通常是在真正的密文前面附加了一个固定的字符串Salted__以及一个8字节的“盐值”然后再整体做Base64编码。所以解密的第一步是对这个字符串进行Base64解码。解码后我们得到一个字节数组。这个字节数组的前8个字节是字符串Salted__接着8个字节是盐值剩下的部分才是真正的AES密文。接下来的关键是如何使用密钥libcckeylibcckey和IVlibcciv libcciv。在真正的AES-256-CBC算法中我们需要一个32字节的密钥和一个16字节的IV。而我们的密钥字符串只有16字节libcckeylibcckeyIV字符串是16字节libcciv libcciv注意空格。这里就是Navicat实现的一个小“秘密”。它实际上使用了PBKDF2函数配合从密文头部提取的盐值对原始密钥字符串libcckeylibcckey进行派生从而生成最终用于AES解密的32字节密钥和16字节IV。PBKDF2是一种基于口令的密钥派生函数它通过多次哈希运算来增加破解难度。但是在我们逆向的特定版本和场景中似乎它使用了一个固定的盐值或者甚至省略了盐值并且直接通过简单的方式比如重复拼接来扩展密钥。社区逆向出的代码直接使用固定字符串作为密钥和IV能成功说明在这个导出文件的加密环节Navicat可能采用了一种简化的、固定的派生方式或者就是直接使用了这两个字符串的字节数组可能前后拼接成32字节。具体到Hutool的实现中当我们用libcckeylibcckey.getBytes()作为密钥传入时Hutool的AES构造器会根据指定的算法AES-256要求自动对这个字节数组进行长度处理。如果长度不够它会进行补全如果像这里它可能会将其直接作为密钥而内部CBC模式需要IV我们就明确提供了libcciv libcciv。所以整个解密流程可以概括为Base64解码将Password属性值从Base64字符串解码为字节数组。提取密文识别并跳过可能存在的Salted__头部和盐值在目前测试的导出文件中似乎没有这个头部密文就是简单的AES-CBC加密后直接Base64的结果。构建AES解密器使用算法AES/CBC/PKCS7Padding密钥为libcckeylibcckey处理后IV为libcciv libcciv。执行解密对密文字节数组进行AES解密。输出明文将解密后的字节数组转换为字符串得到原始数据库密码。理解了这个过程即使未来Navicat版本更新加密方式有所变化你也有了分析和应对的思路。6. 扩展与注意事项不同场景下的应用思考成功解密了一个连接很有成就感吧但实际应用时情况可能更复杂一些。这里分享几个我踩过的坑和扩展思路。场景一处理多个连接我们的示例代码只处理了第一个Connection节点。你的导出文件里很可能有几十个连接。修改代码很简单用一个循环遍历所有节点即可IteratorElement connIter root.elementIterator(Connection); while (connIter.hasNext()) { Element conn connIter.next(); String name conn.attributeValue(ConnectionName); String encPwd conn.attributeValue(Password); // ... 提取其他字段 String plainPwd aes.decryptStr(encPwd); System.out.println(连接【 name 】的密码是: plainPwd); // 可以将结果输出到文件或者存入Map备用 }场景二不同数据库类型的密码我们测试的主要是MySQL。Navicat支持PostgreSQL、SQL Server、Oracle、SQLite等等。好消息是根据测试这个加密方法是通用的无论你连接的是什么数据库只要是通过Navicat导出并选择了“导出密码”其密码的加密存储方式都是一样的。ConnType属性只是用来告诉Navicat该用哪种驱动去连接而已。场景三版本兼容性问题这是我必须强调的一点。我测试的环境是Navicat Premium 15.0.25网络上大部分逆向资料也围绕较新版本12。Navicat的加密机制并非一成不变。早期版本比如Navicat 11或更早可能使用了完全不同的加密方式甚至是简单的异或编码。如果你用本文的方法解密老版本导出的文件失败可能需要寻找对应版本的逆向资料。一个简单的判断方法是看看Password字段的密文是否还是以U2FsdGVkX1开头如果不是那算法可能就变了。安全与伦理提醒这是最重要的一部分。我们研究这个技术目的是自助恢复找回自己遗忘的、存储在本地的数据库密码。合规审计在拥有相应权限的前提下协助进行资产梳理和安全检查。技术迁移将连接配置从一台机器安全地迁移到另一台。绝对不要将此技术用于未经授权访问他人的数据库这是违法行为。导出的.ncx文件包含了敏感的连接信息请务必像保管密码一样保管好这个文件使用后及时删除。在团队协作中也应避免通过明文传输此类文件。7. 除了Java还能怎么解密不是每个人都会Java或者都想为了这个事专门开一个Java项目。别担心同样的解密逻辑可以用多种语言实现。这里我给出一个Python的示例使用pycryptodome这个强大的库思路完全一样。首先安装库pip install pycryptodome然后编写Python脚本from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64 import xml.etree.ElementTree as ET # 固定的密钥和IV key blibcckeylibcckey # 16字节AES-128注意这里需要32字节给AES-256 iv blibcciv libcciv # 16字节 # 实际上我们需要将密钥扩展到32字节AES-256。一个常见做法是直接重复一次。 # 但根据Navicat的实际实现它可能就是这样用的。我们这里按社区验证过的方式 # 有时直接使用这个16字节密钥在AES-256-CBC模式下库会自动处理或报错。 # 更准确的做法是key_32 key * 2 # 重复一次变成32字节 key_32 key * 2 # 将16字节密钥重复一次得到32字节密钥 def decrypt_navicat_password(encrypted_b64): 解密Navicat加密的密码 # 1. Base64解码 encrypted_bytes base64.b64decode(encrypted_b64) # 2. 创建AES解密器模式CBC使用PKCS7填充在Python中通常叫PKCS7 cipher AES.new(key_32, AES.MODE_CBC, iv) # 3. 解密并去除填充 decrypted_bytes unpad(cipher.decrypt(encrypted_bytes), AES.block_size) # 4. 转换为字符串假设密码是UTF-8编码 return decrypted_bytes.decode(utf-8) # 解析XML文件 tree ET.parse(connections.ncx) root tree.getroot() for conn in root.findall(Connection): conn_name conn.get(ConnectionName) enc_pwd conn.get(Password) if enc_pwd: # 如果有加密密码 try: plain_pwd decrypt_navicat_password(enc_pwd) print(f连接名: {conn_name}, 密码: {plain_pwd}) except Exception as e: print(f连接名: {conn_name}, 解密失败: {e}) else: print(f连接名: {conn_name}, 密码未导出或为空)这个Python脚本更加灵活轻量。同样你也可以用Node.js、Go、C#等语言实现核心就是那几步Base64解码、AES-CBC解密、PKCS7去除填充。网上也能找到一些现成的开源小工具但自己动手写一遍理解会更深刻。最后我想说的是这次对Navicat连接文件的逆向分析更像是一次有趣的“探秘”。它揭示了商业软件在便利性和安全性之间所做的权衡。对于我们开发者而言不仅要会用工具更要理解工具背后的行为这样在遇到问题时才能有更多解决问题的思路和底气。下次你再看到那个.ncx文件就知道它不仅仅是一个配置备份更是一个装着所有数据库钥匙的、用固定锁芯加密的宝盒而你现在已经掌握了开锁的方法。