Steam 是如何实现「假入库」的：许可证、清单文件与客户端信任模型

先说现象：有些人的 Steam 库里会出现他们从未购买过的游戏——能显示、能”开始游戏”、甚至能解锁成就。这不是什么黑魔法，而是把 Steam 客户端”本地优先”的信任模型利用到了极致。

写在前面：本文只做机制分析，不提供任何工具的获取方式，也不构成操作教程。使用此类工具违反《Steam 订户协议》（SSA），可能导致游戏库清空乃至账号永久封禁。理解原理的意义在于：看懂风险从哪来、做平台设计时该在哪设防。

一、正常情况下，「入库」是怎么发生的

要看懂”假”入库，得先看懂”真”入库。当你在 Steam 买下一款游戏，后台发生的事情大致是一条这样的链路：

1. 购买 → 授权记录。Valve 服务器在你的账号下记录一条 license（许可证）。注意 license 的单位不是游戏，而是 package（sub）——一个打包集合，里面列着一串 appid（游戏本体、DLC、试用版都是独立的 app）。
2. 登录 → 同步授权。客户端通过 CM（Connection Manager，Steam 的长连接服务器集群）把你的 license 列表同步下来。
3. 展示 → 本地渲染。客户端拿着”license → package → appid”的映射，再结合本地缓存的元数据文件（appinfo.vdf，存放游戏的名称、图标、配置等），把”你的库”渲染出来。
4. 安装 → 本地清单。每个已安装的游戏在 steamapps/ 目录下对应一个 appmanifest_<AppID>.acf，记录安装目录、buildid、状态位、已下载的 depot 等信息。
5. 启动 → 本地校验。steam.exe 只是个壳，真正的客户端逻辑在 steamclient.dll 里；游戏进程内的 steam_api.dll 与本地客户端会话通信，确认”当前用户是否拥有本 app”，通过后 DRM 壳放行。

把这条链路压缩一下，会得到三个对后文至关重要的结论：

1. 你的”库” = 服务器同步来的授权列表 + 本地元数据缓存，展示层完全在客户端本地；
2. “是否拥有”这个判断，在启动链路里发生在本地进程间通信，而不是每次启动都问一遍服务器；
3. “是否已安装”完全由本地 acf 文件决定，客户端默认信任它。

攻击面就在这里。

二、三条「假入库」路线

社区里流传的各类工具，无论包装成什么样子，拆开看基本落在三条技术路线上，或者它们的组合。

路线 A：会话内注入假许可证

这是最”正宗”的一条路，GreenLuma 一类工具的思路。

Steam 进程被注入一个 DLL，后者挂钩（hook）steamclient 中许可证枚举/查询相关的函数，把伪造的授权记录（subid → appid 映射）追加进本次会话的授权表。此后，所有向客户端询问”这用户拥有什么”的代码——无论是库界面的渲染，还是游戏内 steam_api.dll 的所有权检查——读到的都是这张被污染过的表：

• 客户端 UI：以为你拥有 → 游戏出现在库里，有商店页、有”开始游戏”；
• 启动流程：以为你拥有 → 允许进入安装/启动逻辑；
• 游戏 DRM：steam_api 向本地客户端查询所有权 → 通过 → 放行。

这条路线的特点是：一切只存在于本次进程会话中。干净地重启 Steam、重新登录，假授权就消失了——因为服务器的授权列表从来没变过。

路线 B：伪造本地安装清单

appmanifest_<AppID>.acf 是纯本地的 KeyValues 文本文件，谁都能写。手工构造一份（把 StateFlags 置为”已安装”、填好 depot 与大小信息），再把游戏文件预先放进 steamapps/common/<游戏目录>，客户端就会认为”这个游戏已经装好了”，直接提供”开始游戏”。

这条路线解决的是”已安装”，但不解决”是否拥有”——库列表里没有这个 app 时，光有 manifest 是无处安放的。所以它通常与路线 A 配合：A 负责”我有”，B 负责”我装了”。这也是为什么社区里的典型组合总是”外部来源的游戏文件 + 构造的清单”。

路线 C：让游戏自己相信（steam_api 层）

严格说这不算”入库”，因为客户端的库列表根本没变——它是在游戏进程这一侧做文章。

很多游戏的防盗措施只有 Steam DRM 壳加 steam_api 的本地校验，没有任何服务端票证验证。而 Valve 官方 SDK 里存在一个开发模式机制：steam_appid.txt（这一点写在 Valve 的合作伙伴官方文档里）会让 steam_api 以开发模式初始化、跳过所有权检查；另有 Goldberg Emulator 这类开源项目，直接用本地实现替换 steam_api.dll，模拟出一个”永远合法”的 Steam 会话。

路线 C 的存在解释了一个现象：有些假入库方案对部分游戏”不管用”——那些游戏在关键路径上还有服务端确认，本地骗过 DRM 壳也没用，得靠 C 路线补刀。

三条路线对比

路线	改动的对象	骗过了谁	何时失效
A 假许可证	内存中的授权表（hook）	客户端 UI、steam_api 所有权查询	干净重启/重新登录
B 假清单	本地 appmanifest_*.acf	客户端的安装状态判断	完整性校验/depot 校验时
C 绕过 steam_api	游戏侧校验环节	游戏 exe 的 DRM	存在服务端票证校验的联机功能

三、为什么「能启动」，却常常「下载不了」

一个常见的困惑：既然客户端都以为我拥有这游戏了，为什么点”安装”还是失败、或者卡在 0%？

因为真正的硬防线不在客户端，而在内容分发（CDN）这一层：

• 客户端发起下载前，要先向服务器索取对应 depot 的授权票证（ticket / CDN key）；
• 票证由服务器签发，签发前会校验这个 package/app 是否真的在你的账号授权里；
• 伪造的 license 过不了这一步，绝大多数 depot 会直接拒绝；
• 例外是免费游戏、Demo、部分公开 depot——它们本来就不需要授权票证，所以人人可见可下。

这一层设计直接决定了假入库的形态：它只能启动已经存在于本地的文件，骗不开下载这道门。所谓”文件从哪来”的问题，Steam 体系本身不提供答案——这也是此类用法始终与盗版文件分发纠缠在一起的原因。

除了下载，服务器还掌握着另外几样东西：DLC entitlement 校验（不少游戏的 DLC 有服务端确认）、联机票证（VAC 服务器、专属服务器认证）、以及成就与游戏时长的上报——上报可以先落地，但也可以事后清算，Valve 有过回收异常获取物品/成就的先例。

四、服务器不是全知，但账总会算

从 Valve 的视角看，假入库留下的痕迹相当显眼：

• 账号从未购买某 app，却持续上报该 app 的成就、游戏时长、截图；
• 家庭共享（2024 年起是 Steam Families）里，共享出了账号从未真正拥有的”车库”；
• 大量账号在相近时间共享同一个伪造车库的模式。

这些模式在服务器日志里是批量可检出的。社区与媒体都报道过多轮针对此类用法的限制与封禁。这里有三个容易搞错的重点：

1. 处罚依据是 SSA，不是 VAC。VAC 管作弊，假入库走的是”违反订户协议”这条线——而违反 SSA 的处置可以不经警告直接执行，且永久封禁往往附带库内全部游戏的没收。
2. 被连坐的不只是工具使用者。把伪造车库共享给家人朋友的小号，在 Steam Families 的模型下同样留下”获得过从未存在的授权”的记录，连带处置并不罕见。
3. 最大的现实风险其实是工具本身。这类工具的本质是”往 Steam 进程里注入代码的高权限 DLL”，而它们天然只能从小众渠道分发——假官网、二次打包、捆绑木马在这类生态里是常态。为了省一份游戏钱，把整个 Steam 会话（登录态、支付凭据的入口）暴露给来路不明的代码，这笔账怎么算都不划算。

另外还有一层不那么戏剧性的代价：稳定性。hook 的函数地址、appinfo 的结构都会随客户端更新变化，工具失效、库显示错乱、残留清单导致客户端反复校验，都是使用者的日常。

五、不碰灰色手段，想要类似体验的正规姿势

• Steam Families：官方家庭共享，2024 年取代旧的 Family Sharing。家人各自保留自己的存档与成就，同时能玩彼此库里的游戏——这就是”共享车库”的合法形态；
• 免费周末（Free Weekend）/ Demo：很多大作的免费周末本质上就是官方发的”临时授权”，效果与”临时入库”完全一致；
• 2 小时 / 14 天退款：把”试错”成本压到最低，玩两个小时不合适就退；
• 特卖 + 捆绑包 + Key 比价站点：叠加优惠券后的史低价，经常低于心理预期。

六、写给做客户端的人：这场攻防的设计启示

如果把 Steam 当作一个大型客户端软件的攻防案例来看，它对任何做启动器、平台的人都很有参考价值：

1. 本地状态只配做展示，不配做关键决策。库列表、安装状态、所有权——Steam 自己的划分很清晰：前两者交给本地（所以能被伪造），“所有权”的最终权威留在服务端。骗得过 UI，骗不开 CDN。
2. 信任边界画在”谁签发”，而不是”谁能读到”。acf 文件谁都能写，所以它只能承载”我装过什么”这类可重建、可校验的信息；一旦把”能不能玩”也寄托在本地文件上，就是在邀请伪造。
3. 宽松是有代价的，关键是把值钱的东西放对位置。离线模式、秒启动、兼容十年前的老游戏，这些体验的代价就是本地信任面扩大。Valve 的选择是把体验层放本地、把真正值钱的东西（内容分发、交易、联机、账本）放服务端。
4. 事后审计比事前拦截更省钱。服务器不阻止本地”演戏”，但异常上报模式会被批量清算。对很多场景来说，“允许发生 + 事后可回滚 + 保留完整账本”比在每个客户端里塞满校验更务实。

结语

“假入库”并不是什么神秘的破解，它只是把 Steam 客户端里那些为了体验而让渡出去的信任集中利用了一遍：授权列表可以注入，安装清单可以伪造，游戏侧校验可以绕过。但内容分发与账本握在服务器手里，所以它注定停留在”本地演出”的层面——演给谁看？演给本地那几个进程看。

至于服务器，它不说话，但它一直记着。