This could very well be a simple bug where it's supopsed to XOR with some really random string generated on the server, but some replacement of a template string isn't happening which is why it XORs with RANDOM_STRING.
Of course this is only marginally better and should really have been caught, but there's a huge difference between saying that XORing 12 bytes with RANDOM_STRING is kick-ass DRM and actually having a kick-ass DRM infrastructure that then doesn't work right because of a bug.
If this was any really random looking string, I would be more inclined to assume that this was intentional. By the string being this token, I would guess it's a bug somewhere.
Remember. If RANDOM_STRING was truly random, unique per file and account and only transmitted from the server before playing, then this would be as good an encryption as any.
That wouldn't be better. Intercepting the decoded movie is trivial either way. Finding the encryption scheme was just a fun exercise and discovering the random string (even if it isn't "RANDOM_STRING") once you have the decrypted copy is trivial as well.
My understanding is that when using the xor cipher, even if the key is truely random, the file could still be trivially completely decrypted for a repeating key. It seems like a rather unwieldy cipher if you need to download a key which is nearly the same size as the video file.
Of course this is only marginally better and should really have been caught, but there's a huge difference between saying that XORing 12 bytes with RANDOM_STRING is kick-ass DRM and actually having a kick-ass DRM infrastructure that then doesn't work right because of a bug.
If this was any really random looking string, I would be more inclined to assume that this was intentional. By the string being this token, I would guess it's a bug somewhere.
Remember. If RANDOM_STRING was truly random, unique per file and account and only transmitted from the server before playing, then this would be as good an encryption as any.