前几天晚上跟一个做安全的朋友聊天，话题莫名其妙滑到截屏上。他问得很直接，手机截屏到底怎么实现的，我说把合成好的那一帧拷出来就行；他接着问那防截屏怎么防，我说给窗口打个标记，合成的时候把这块挖掉，屏幕照常显示，你截就是黑的。
他说，那我在下游伪造一块屏幕呢。
我当时答得挺快——没用，你伪造的屏幕在系统眼里就是另一块显示设备，过滤逻辑一样跑一遍，拿到的还是黑的。他想了想，又问了一句让我卡住的话：如果我不造假屏幕，我找一台认证过的显示器，把液晶面板拆了，屏线接到采集芯片上，行不行？
那天晚上我回家翻了不少资料，翻完发现我前面那个回答里有一半是错的，而且错得挺典型：我用加密的框架去想了一个认证的问题，还说得理直气壮。
这篇就把那一晚上的推演记下来，从截屏抓到的是哪一帧开始，一层一层往下走，走到水印为止，中间经过四条防线，它们挡的人完全不一样。
先说结论
- 截屏抓的是合成之后的一帧，不是屏幕。所以你眼睛看得见的东西理论上都能被拷走，差别只在系统让不让你拷。
- 防截屏的本质是在合成器上打标记。打了标记的图层在「可被捕获的那份输出」里直接消失，屏幕照常显示，因为那本来就是两条路。
- 在下游伪造屏幕确实没用。过滤发生在上游，你换掉的只是水管末端，水在源头就变颜色了。这一条我一开始说对了。
- 但换掉认证显示器的面板排线是真能通的。链路加密不是一道需要解开的谜题，是一次认证，认证芯片本身是真的，它下游接到哪里没人管。这一条我一开始说错了。
- 真正拦住高价值内容的不是加密，是发流之前的分级判断和事后的水印溯源。前者你能合法进入，后者你冒充不了。
一、截屏抓的是哪一帧
手机屏幕上的画面不是一张图，它是叠出来的，状态栏、App 内容、悬浮窗、输入法各是独立图层，各自有一块自己的缓冲区，谁也不清楚别人在上面画了什么。App 只往自己那块里画。
它既不知道整屏长什么样，也没有权限和手段去把别人的图层拼起来——如果它能拼，那任何一个恶意应用都能实时偷看你的整个屏幕，这个风险系统早就不允许存在了。
所以截屏这个动作必然是向系统要——要的对象是合成器刚叠完、还没送去显示控制器的那个中间结果，它是所有图层叠加之后的成品，但还没有被任何一条输出通道处理过。
拿到手的是一块裸像素，外加一个分辨率，没有压缩、没有图层信息、没有任何元数据，就是一整片 RGB 数值。之后编码器把它压成 PNG 或者 JPEG。
PNG 无损，文字边缘是锐的，体积大；JPEG 有损，几兆能压成几百 K，代价是文字周围会出现那种发虚的色斑。这也是为什么同一块屏幕截出来的图，用不同工具得到的文件大小能差十倍。编码参数不一样，跟截屏本身没关系。
按键组合在这里只是个信号，音量下加电源的作用就是给系统服务发一个截屏事件，它本身什么都不截，而手势、三指下滑、语音助手全都进同一个入口。所以我一直觉得「截屏键」这个叫法有点误导，它其实是个遥控器。
长截屏是暴力拼接——滚动一次抓一张，靠重叠区域做特征匹配对齐再缝起来，所以页面里只要有固定不动的悬浮按钮、正在播放的视频、来回转的加载动画，拼出来必然糊或者重复。有些工具更偷懒，按滚动距离硬拼不做匹配，出来的长图连滚动条位置都是错的。
第三方截屏 App 走的是另一条路：录屏接口。Android 上是 MediaProjection，iOS 上是 ReplayKit，取的是同一路画面数据，只是只留一帧——这就是它们必须弹「将开始录制或投放您的屏幕」的原因，跟礼貌无关。
这条录屏路径还有副作用：开始录制之后系统会在状态栏挂一个常驻提示，部分版本还不允许隐藏。所以用第三方 App 截敏感页面，截图能不能成不知道，先多一条记录。很多人以为绕开了系统限制，其实只是换了个人代劳。
顺便说一句，录屏比截屏危险得多。截屏是一帧，录屏是连续帧，能还原操作过程、输入节奏，甚至猜出一部分键盘敲击的时序，所以不少 App 对录屏的检测比截屏更严——只不过这个动作在系统层本来就是可见的，藏不住。
二、防截屏：同一帧分两条路走
最主流的做法是给窗口打一个标记，Android 上它叫 FLAG_SECURE，一行代码的事，打上之后这个窗口在合成器眼里就变成了不可捕获图层。所有走拷贝通道的输出里都不会再有它的内容。
这里的关键是「两条路」：送到屏幕的那份完全正常，被抹掉的只是「可被捕获」的那份。这个设计不是为了刁难谁，而是因为系统里显示和拷贝本来就是两套输出，投屏、录屏、截屏、系统级画面共享全都走拷贝那条。
生活里的验证太多了——手机投屏到电视，银行 App 和支付页面就是黑的，因为电视就是一块外接屏，走的是同一条过滤逻辑。同理还有 Netflix 的高清片源、某些企业办公套件、部分网银的转账确认页。
代价是它连用户自己也一起防了。余额页截不了图，客服要求提供凭证的时候很难受；有些单位的报销流程要截图，员工只能拿另一台手机对着拍，拍出来全是摩尔纹。做过这类 App 的人应该都接过这种投诉。
iOS 那条路不太一样，它没有公开的「禁止截屏」接口，业内常见两种做法。第一种是监听系统截屏事件，收到之后弹个提示或者盖一层遮罩，这是事后知情，图已经存进相册了，你只能让用户知道，拦不住。
第二种流传得更广：把一个 secureTextEntry 的输入框垫在视图最下面，系统会把这层从截屏输出里排除掉，于是整个页面都截不到。这是个 trick，Apple 从来没正式支持过，系统版本一变就可能失效——具体在哪些版本上还管用，我没有可靠依据，不下结论。
见过一些 App 把两招叠着用，遮罩加监听，体验很差，但确实把普通用户拦住了。至于专业的，两招都不构成障碍。
有人会问，既然技术上禁得掉，为什么不干脆全禁。因为截屏早就不是边缘功能了：客服凭证、报销、bug 反馈、教程截图，全都建在它上面，一个连截图都不让的系统，用户第一时间就会卸载。所以标记只能按页面打、按场景打，打得越准，用户越不容易察觉。
三、那换成虚拟屏幕行不行
既然防的是「屏幕这个出口」，一个很自然的想法就是不给它真屏幕。PC 上这是成熟技术——虚拟显示驱动在系统里注册一块屏，任何往这块屏输出的内容都能被抓下来，OBS 那一类工具干的就是这件事。
手机接 HDMI 采集卡也一样，走 USB-C 的 DP 模式，系统认为外接了一块显示屏，画面就流过去了，整个过程里没有任何一步需要欺骗系统。
但这条路走不通，原因很干脆：过滤发生在上游，不在显示设备。虚拟屏对系统来说只是又一个显示设备，合成器往它输出的时候执行的是同一套逻辑，你拿到的是已经被抹黑的画面。
你换掉了水管末端，但水在源头就变了颜色。
有人会说 Android 明明能创建虚拟显示——能，新版本有专门的接口，用途是给投屏、录屏和桌面模式提供一块逻辑屏幕。但受保护窗口在虚拟显示上应该照样是黑的，这一点我标为推测，没有实测过那个具体接口下的行为。
云手机和群控那一类方案在这上面踩过坑——看着设备连上了、画面也有，可一到支付页面就是黑的，到头来都归结为同一件事。它们以为自己在抓屏，其实是在抓一份已经被过滤过的副本。
四、我在这儿答错了一次
聊到这儿我给的结论是：行，你伪造屏幕，但链路是加密的，你也解不开。这句话错了——HDCP 不是一道需要破解的谜题，它是一次认证。
握手过程是这样的：发送端问接收端，你的密钥是什么、能不能按约定算出校验值，算对了就放行，之后发的确实是加密流，接收端解出来是明文。整个过程里没有任何需要猜的东西，它验证的是你是不是一台被信任的设备，不是你能不能看懂。
所以只要你手里有一颗合法的接收芯片，握手天然通过，出来的就是明文像素，你不需要破解任何东西。市面上那些 HDMI 采集卡就是这么工作的，它们没有攻破 HDCP，它们本身就是被授权的下游设备。
顺带说一段历史：HDCP 1.x 在 2010 年翻过车，主密钥被公开，Intel 确认过这件事，所以现在的高清内容一律要求 2.2 以上，1.4 只够放标清。这条防线本来就是加密强度层面的东西，破了一代就换一代，不是靠设计巧妙撑住的。
回到我那个错误：我在用加密的框架讨论一个认证的问题。听起来很专业，实际上是两回事，而且这两回事的攻防思路完全相反——加密你想着怎么算出来，认证你想着怎么变成那个被信任的东西。
后者往往比前者容易得多。算法可以设计得极难，身份只需要想办法借过来。
五、真正的闸门在发流之前
那为什么拿采集卡录 Netflix 还是黑屏，或者糊得没法看？因为拦人的地方根本不在链路里，在内容发出来之前，播放器会先查三件事：这台设备是不是通过了内容保护认证、链路的加密等级够不够、输出路径是否受保护。
这三条不是播放器自己说了算的，是服务端给的信任，三条全过才给原画质，任一条不过就降级或者干脆拒播。所以你即便把链路完全解开，解到的也是对方认为这条链路配得上的那一档。
这里有个概念值得分开：加密保护的是传输中，分级保护的是传输前。前者你能合法进入，后者你冒充不了，因为判断依据是设备身份，不是链路上发生了什么。
| 想做到的事 | 结果 | 原因 |
|---|---|---|
| 拿到 HDCP 保护下的明文像素 | 能 | 授权接收芯片本身就是合法下游设备 |
| 骗出最高分辨率输出 | 能 | EDID 可以任意伪造，报一块 4K HDR 屏没问题 |
| 让服务端相信你是认证播放设备 | 不能 | 需要安全执行环境里的设备证书 |
| 拿到对方不打算下发的那一档画质 | 不能 | 这一档内容从未发送给你 |
举一个能被用户感知的例子：同一台手机装两个播放器，一个能放 1080p，另一个只给 480p。不是硬件不一样，是其中一个没拿到 L1 认证——它做不到在安全环境里解密和渲染，服务端就按低一档发。用户看到的是画质差，背后是一次设备身份判定。
手机在这条路上更窄，一是手机本来就没多少 4K 片源，二是 App 检测到外接显示往往会直接降级——这是经验判断，具体到某个 App 怎么处理取决于它自己的实现。
但要注意，这个机制保护的是「原画」，不是「画面」。降级流照样能被完整抓下来，只是画质差，而对盗版站点来说一个 540p 的版本也是有价值的，这也是为什么流媒体平台的盗版源大多是模糊的枪版画质。分级不阻止复制，它让复制出来的东西不值钱。
六、把排线换掉
朋友最后那个问题才是真问题：我不造假屏幕，我拿一台真的、认证过的显示器，把液晶面板拆了，屏线接到采集芯片上，行不行。
行——而且这条路比造假屏幕靠谱得多，因为认证芯片本身是真的，你没有伪造任何身份，只是把它的下游换了，握手正常、校验正常、播放器认为我连了一台合规显示器，然后照常下发。
面板线上跑的是什么？明文像素——eDP、LVDS 这些接口在机箱内部，物理上被当作安全域，不加密。这是整个链路里唯一一段「默认没有人会伸手」的地方，而它恰恰伸手最容易够到。
这就是业内说的 analog hole，末端模拟口。原则上堵不死，因为你没法既让画面显示出来，又让它在最后一段不以明文形式存在，除非让屏幕自己成为可信的一部分，而那又回到了硬件成本上。
工程上有几道坎，别想得太轻松：
| 障碍 | 具体情况 | 难度 |
|---|---|---|
| 面板在位检测 | 时序芯片常要读面板的 I2C 参数或检测背光负载，缺了面板可能直接不启动 | 高，得仿真应答 |
| 高速信号捕获 | eDP 是 4 lane 差分，单 lane 数 Gbps，要匹配的接收芯片或 FPGA 加高速串行接口 | 中，有现成器件 |
| 时序参数 | 前后肩、极性、lane 映射不在 EDID 里，得翻面板规格书或拿示波器量 | 中，纯工作量 |
| 「解码还原」像素 | 不需要。面板线上跑的就是明文 R、G、B，采下来即是像素 | 无 |
表格末行是在纠正一个说法：这里没有「还原」这个环节。只有你拿探针去抓物理层的电信号才需要解串，从面板接口取数，出来的直接是图像。
另外解释一下为什么这条路没被 HDCP 的本地性检查拦住——那个检查是量往返时延、判断接收端是不是真在附近，专门用来防有人中途插设备。而你什么都没插：认证芯片还在原位正常应答，面板只是被换成了别的东西，拓扑没变，检查不会触发。
顺带回答一个常见的疑问：既然采集卡本身合法，为什么还要折腾改显示器。因为便宜的那些只支持 1.4，高清内容根本不会往下发，插上去就是黑的；支持 2.2 的采集卡不便宜，而且要能被系统识别成一款可信设备，能做这件事的型号本来就不多。改显示器这条路门槛在动手能力上，不在采购上。
所以结论得改过来：这条路是真的通。4K 片源泄漏里有一部分就是「认证设备加录制卡」这个组合出来的，不是因为攻破了什么，是因为压根没经过任何非法环节。
七、最后一道墙是水印
走到这里，技术上已经没有墙了，行业能想到的办法很务实：承认这一点，然后换目标。
水印分两类，能不能去掉的答案完全相反。可见水印就是叠在画面上的半透明 ID，能去，它本质是一层 alpha 混合，估出位置和透明度就能反解，或者用修补算法把区域补上，代价是补过的地方有痕迹。
取证水印，藏在音视频数据里的那种，基本去不掉。这两者的区别在设计目标上：可见水印防的是「看」，取证水印防的是「跑掉」。
为什么去不掉？三个原因叠在一起。一是分散，它不嵌在某几个像素或者某几帧上，而是散布在整帧所有块、整段时长里，每处只动一点点，你削掉任何一块都不影响判决，因为检测器靠的是全片统计累积，冗余度高得离谱。
二是强度低于视觉阈值——你看不出来它在哪，盲去等于盲修，没有坐标系，改哪里都要靠猜。而猜错的代价是画质——真要暴力重构一遍，内容本身也就毁得差不多了。
三是最要命的一条：你没有检测器。改坏了没有，自己验证不了，检测需要密钥和专用工具，普通人拿不到。所以市面上号称去水印的服务，多数是在赌，赌完还没法确认赌赢了。
真正有效的攻击只有一条：多份拷贝对比。同一部片子你手上有两份，内容一样、水印不同，做平均或者取中值，内容互相抵消，水印就浮出来了。这叫合谋攻击，是水印方案在设计阶段就要防的东西。
防法是用抗合谋编码，比如 Tardos 码：即便几个人把各自的拷贝平均，编码结构也保证至少能锁定其中一个。所以这条路能削弱水印，代价是把自己暴露出来——合谋攻击听起来是攻击，实际是一次自首。
反过来，重拍没用。屏幕重拍会带来几何畸变、摩尔纹、色彩偏移、滚动快门，而水印在设计时就是照着「扛住影院盗录」这个目标做的，你重拍一遍它还在，只是画面变得更差，等于自己给内容降了一次质。
还有两个名字值得分开看。Cinavia 是音频水印，嵌在人耳不敏感的频段，业内公认极顽固，但它的目的不是溯源而是播放控制——正规播放器检测到就静音或者停播，让盗录版放不出来。
AACS 的取证水印则是每次分发嵌不同的 ID，目标是扛住整条分发链路的转码和压缩，所以它能定位到具体是哪一台设备、哪一次播放流出去的。
水印也不是白来的。嵌入要占带宽、占算力，重复检测得跑在服务端，一套做下来对平台是实打实的成本，所以它只用在值得的地方——院线片、提前点映、审片系统，普通短视频不埋。这也是为什么你很少听说某个日常视频被水印追到人。
所以水印的哲学和加密完全相反：加密假设内容能被挡住，水印承认挡不住，把防线挪到事后追责。这也是为什么高价值内容的保护重心，这些年从 DRM 慢慢往水印加法律手段偏。
说白了，加密在赌「你拿不到」，水印在赌「你拿到了也不敢用」。后者明显更现实一点。
八、几个我拿不准的地方
上面那些是能站住的，下面这几处我给不了确定结论，写在这儿免得看着像什么都懂。
消隐动作到底是软件做的还是硬件做的。如果是合成器往缓冲区里写 0，那下游拿到的那块内存本身就没内容；如果是显示控制器在扫描输出时按标位跳过图层，内存里可能还留着完整帧，攻击点就得落到 GPU 到显示控制器之间的总线上，用探针抓。不同厂商、不同系统版本做法不一致，我没有可引用的实测数据。
HDCP 2.2 以上有没有被公开攻破，1.x 那段是公开历史，2.x 我没有可信记录，不给推测。各家自研的取证水印具体用什么算法，也不清楚。
还有两条我写在上面但只是推测：Android 虚拟显示上受保护窗口的实际行为，以及小米这类显示器内部用哪颗时序芯片、有没有面板在位检测。这类结论最好自己拿一台机器跑一遍再信。
收个尾
这一晚上翻下来，收获最大的不是那些原理，是我最开始那个反应：用加密的框架去想一个认证的问题，然后给出一个听起来很专业的错误答案，而且我还说得挺有底气。
如果你只是想搞清楚为什么银行 App 截不了图，看到第二节就够了；如果你想做屏幕录制或者采集，第五、六节讲的是那条路的边界在哪。
至于防截屏本身，我的看法是：它挡的从来不是有心人，是顺手的人。真要让画面流不出去，最后还得靠水印——承认挡不住，然后让拿走的人跑不掉。
这思路听着挺泄气，但比假装防住了要诚实。
如果你觉得这篇文章不错，有用的话可以点击下面的“赞赏”支持作者，你的支持是我更新的动力（饿饿吃饭）。
Comments NOTHING