[FFmpeg-devel] Using decryption keys in a decoder

Maxim max_pole
Tue Apr 7 19:15:12 CEST 2009


Reimar D?ffinger schrieb:
> On Tue, Apr 07, 2009 at 05:01:11PM +0200, Maxim wrote:
>   
>> simple XOR...
>> The encryption key is derived from the password named "AccessWord"
>> entered by the user as follows:
>>
>> uint32_t   k1 = (AccessWord >> 1) + 16384;
>> uint32_t   k2 = (k1 / 200) * 200 + 21;
>> uint32_t   k3 = (~AccessWord) >> 16;
>>     
>
> Does the lowest bit of AccessWord have any meaning?
>   

Here it seems to have no meaning, but in the hash function takes it in
account...

>   
>> for (i = 0; i < size; i++) {
>>    k3 = (k3 * k2 + 1) & 0xFFFF;
>>    dataPtr ^= k3;
>>    dataPtr++;
>> }
>>     
>
> Why uint32_t above? Seems like everything is uint16_t.
>   

Right, the whole loop operates on uint16_t...

>> I don't know if it may be any kind of known encryption algorithm but
>> it's how it works...
>>     
>
> Depends on how you define "known", it is "xor by pseudo-random number
> generator", should be brute-forceable easy enough (about 24 bit key
> strength I think), though probably not easy enough to do it in realtime.
>   

I wonder if it's possible to find the key doing the reverse of the hash
function. Then it might be done in realtime. The only question is risen
"is the hash is unique"?
Here is it:

a = check_sum + (access_word & 0xFF00) + 1;
b = (access_word >> 16) + ((access_word & 0xFF) << 8) + 1;
im = a * b;
c = (im % (access_word & 0xFF) + 1) + 1;
im /= c;
d = (im % (check_sum & 0xFF00) + 1) + 1;
hash = im * d;

where "check_sum"(uint16_t) is supplied with the bitstream and
"access_word" is the password entered by the user...

> Of course an obvious question would be if the demuxer could decrypt it
> or if that would be too ugly.
>   

I'm afraid it won't work because not all frame bytes are encrypted but
only first 64 bytes of the 1st luma band (it makes the whole
frame+following delta frames unusable though!). The demuxer need to have
knowledge about the indeo5 bitstream layout in order to decrypt the data
properly. BTW indeo5 streams can be delivered using asf/ivf(Indeo video
file) containers as well...

Regards
Maxim



More information about the ffmpeg-devel mailing list