3 ms·
Video RAM is accessible to the OS, if you render into it it can be read back. In this case it's deliberately rendered into a separate protected area of RAM the
by mjg59 2y ago
Video RAM is accessible to the OS, if you render into it it can be read back. In this case it's deliberately rendered into a separate protected area of RAM the OS can't read, and composited at scanout time.
- krackers 2y agoCompositing is done by the OS though (WindowServer in case of mac). Ever since OSX stopped allowing direct framebuffer access I think the only way to read (e.g. for screenshots) windows of other processes' is by asking WindowServer to do it for you, so I'm guessing that's how this protection is implemented. WindowServer ultimately still needs to get access to the framebuffer somehow though, so there must be some private API somewhere to bridge kernel and userspace part. I suspect if you could bypass SIP or just write a kext to access video memory directly then it'd be possible to defeat this protection.
- mjg59 2y agoCompositing into the framebuffer is done by the OS, the compositing of the DRMed video stream into the output is done in hardware. The OS literally has no visibility into the decoded content. You suspect incorrectly.