Vino等VNC服务端不存储明文密码，其~/.vnc/passwd文件仅含8字节salt与8字节3DES密文，属不可逆认证凭证；C++可读取字节但无法还原原始密码，因无公开密钥、IV及标准解密接口。
Vino（GNOME 的 VNC 服务器）和大多数传统 VNC 服务端（如 TightVNC、RealVNC）**不以明文存储密码，也不提供“读取密码文件还原原始密码”的合法途径**。它的密码文件（通常是 ~/.vino/vnc-server-config 或 ~/.vnc/passwd）保存的是经过哈希或加密处理的凭据，且设计上就是不可逆的。
为什么直接“读取密码”在技术上行不通
Vino 使用 GTK-VNC 库，其密码验证依赖于 vncpasswd 兼容格式：对密码执行 3DES 加密（使用固定盐 + 硬编码密钥），结果写入 ~/.vnc/passwd（8 字节 salt + 8 字节密文）。该过程无标准解密接口，且密钥未公开 —— 这不是加密存储，而是**单向认证凭证封装**。
常见误解是把 passwd 文件当成可解密的数据库；实际上它只用于比对，C++ 程序无法从中还原出用户输入的原始密码字符串。
- 试图用 OpenSSL 或自写 DES 解密会失败：缺少正确初始向量（IV）与密钥调度逻辑，且 Vino 实现有非标 padding 和 salt 处理
-
glib或gtk-vncAPI 中没有任何函数暴露解密能力 ——vncauth_get_password()只接受用户输入并做校验，不反向推导 - 即使拿到
~/.vno/vnc-server-config，它只控制启用/禁用、端口等策略，不含认证数据
如果你需要程序化验证 Vino 密码（比如做登录代理）
唯一合规方式是调用 Vino 自身的认证流程，而非解析文件。实际可行路径只有：
立即学习“C++免费学习笔记（深入）”；
- 通过 D-Bus 调用
org.gnome.Vino接口（如果服务开启且权限允许），但该接口不暴露密码校验能力，仅支持启停/配置查询 - 启动一个临时
libvncserver实例，用rfbAuthCheck回调模拟服务端行为，传入待测密码和已知passwd文件内容进行比对 —— 这需要链接libvncserver并复用其rfbAuthNewClient()内部逻辑 - 最简单可靠的做法：用子进程调用系统
vncviewer -passwd /path/to/passwd host:0并捕获连接结果（需配合 dummy X server 或 headless 模式），但属于黑盒集成，非纯 C++ 实现
读取 ~/.vnc/passwd 文件本身（二进制解析）
你可以用 C++ 打开并读取该文件，但只能拿到原始字节，无法语义化解析为“密码”：
#include <fstream>
#include <iostream>
#include <vector>
int main() {
std::ifstream f("~/.vnc/passwd", std::ios::binary);
std::vector<char> buf((std::istreambuf_iterator<char>(f)),
std::istreambuf_iterator<char>());
// buf[0..7] 是 salt，buf[8..15] 是密文
// 后续字节（如果有）可能是其他字段，但 Vino 通常只写 16 字节
std::cout << "Read " << buf.size() << " bytes\n";
}
注意：~ 在 C++ 中不会自动展开，必须用 getenv("HOME") 拼接；且需确保进程有权限读取该文件（通常属主仅读）。
真正卡住的地方从来不是“怎么读文件”，而是误以为读到字节就等于拿到了密码 —— 实际上你拿到的是一把不能打开任何锁的、铸死的钥匙模型。
