> The question then becomes, whether Adblockers could use this information to skip the ads. It's a cat and mouse game.
I wouldn't call it a cat and mouse game because there is nothing from a technical point of view that prevents adblockers to use this information to skip ads. Unless YouTube gets completely rid of the concept of timestamps for their videos, they will always lose this battle.
They could make the timestamp conversion very Server-Side or create a very unwieldy API where it's difficult to collect all ad segments via timestamp sampling.
> For one thing, this approach seems to inherently conflict with the fact that you can link directly to a particular timestamp in a YouTube video, either in an external link using the `&t=...` URL parameter, or by just including a timestamp in a YouTube comment.
The more I think about this, the more I belive that this is literally the only reason that ad blocking cannot be meaningfully defeated for video on emand. Because of the concept of referencing a fixed point in the video by a time stamp, there will always need to be a mechanism to offset the time stamp with respect to the injected ads, which, in turn, gives ad blockers the ability to find out where the ads are exactly.
> What does "server side injection" actually mean?
The way ads usually work is that they are separate video files that are fetched by the YouTube client (e.g., the browser) and then displayed to the user. Ad blockers modify the content of the web site such that the URLs to those ads (usually embedded in some JSON object from an API endpoint or something like that) get removed so that no ads are displayed.
Server side injection in this context means that the server renders a video file on demand that contains the original clean video plus a few ads here or there. Blocking the ads now is much harder because you cannot simply manipulate API responses containing refrences to those ads because there is only this one video file. Instead you would need to implement a mechanism that skips those ads in the player.
AFAIK server sie injection is already done on twitch for live streams where blocking ads is really basically impossible because you cannot skip anything in a live stream. I think the best solution for twitch to get rid of ads is to use a VPN/Proxy in a country where no ads are delivered for contractual reasons.
It's a nice idea, but I don't think it adds enough clarity to the code to justify the messy compiler warnings and errors that this kind of preprocessor abuse will eventually cause.
The "client" whose "identity" is abused here is not an end user. A "client" in this context is a program or library that talks to the license servers and receives the content decryption keys. On my Windows machine I see a "Windows.Media.Protection.PlayReady.dll", which I guess is the client that they cracked. Maybe there are also other clients that are widely accepted by license servers.
The attack essentially means that they could write a program themselves that acts as "Windows.Media.Protection.PlayReady.dll" to get decryption keys from a server. What will happen now is that Microsoft will deprecate the client and release a new one with new obfuscation and new keys. The license servers will start rejecting the old cracked client. And then people will crack the new client. And the cycle continues.
> The "client" whose "identity" is abused here is not an end user. A
"client" in this context is a program or library that talks to the
license servers and receives
Thanks for the clarification.
Otherwise people would be worried about being targeted and having
"personal" keys tied to a financial account or online identity getting
sold and used by others to access arbitary content.
This seems kinda good news for concerned users, but even worse news
for Microsoft.
Does PlayReady now require a secure enclave/TPM on your PC? Otherwise as you say, the only thing protecting the keys is obfuscation. This has been the same way all the way back to the first Microsoft DRMv1 in 1998 (?).
The decryption keys have to be stored on your device so you can play your media or your game. So, the level of encryption is totally moot. The level of obfuscation is all that really protects the content.
With PlayReady, as with any other DRM scheme really, there are different tiers. There is SL2000, which is done completely in software (whitebox crypto), and there is SL3000, which does require a TEE. Which tier is requried for which type of content is driven by streaming provider or studio requirements. I think it is pretty common to allow content up to 1080p to be used with whitebox crypto, whereas 4k+ content will require hardware DRM.
Reading the comments here makes me feel guilty. I'm sitting on probably a few hundred files and folders called something like tmp, tmp1, foo, foo23, foobar, testxyz, etc...
They all hold probably very irrelevant stuff and are safe to delete, and I have yet to resort to those files for rescue, but you never know! Every now and then I collect them and put them in an archive folder. I'm now at "archive10".
Since I'm a bit late to the party and feeling somewhat overwhelmed by the multitude of articles floating around, I wonder: Has there been any detailed analysis of the actual injected object file? Thus far, I haven't come across any, which strikes me as rather peculiar given that it's been a few days.
I agree, I haven't seen anything about decompiling the object file.
If I had a project to develop a backdoor to keep persistent access to whatever machine I wanted, it would make sense that I would have a plug-in executable that I would use for multiple backdoors. That's just decent engineering.
Fascinating work. I know that people did the same for Super Mario 64 [1]. It is still unbelievable to me that they can generate a bit-by-bit identical copy of the original ROM by simply running some old gcc on actual C source code files. IIRC the main insight was that Nintendo did not use any optimization flags which made it possible to create a 100% matching binary. I've never really looked into it, but I guess the did some try and error to figure out the exact gcc version that Nintendo used to make sure that they get 100% identical binary code?
SM64 uses SGI's IRIS Development Option (IDO) compiler. And yes, it's unoptimised.
Paper Mario, however, /does/ use GCC, and it's optimised. Figuring out the compiler version was fairly easy as there's a limited number of options - we know when the game began development, so we looked for releases around that time. The harder parts were figuring out compiler flags (consider all the -f flags affecting code generation; papermario used -fforce-addr) and coming to the terrifying conclusion that the compiler was modified!
The majority of papermario was built with a modified build of GCC 2.8.1 [1] at -O2. The SDK code (libultra, nusystem) was built with GCC 2.7.2 at -O3. The iQue Player version, i.e. the Chinese release, was built with EGCS.
The changes were much more extensive than just removing the debug flags.
They were also able to get local coop and a 4 player split screen working which were features originally intended for the game but cut for performance reasons.
