Thursday, March 9. 2006
Reverse engineering onlinetvrecorder
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Hello!
I don't know if you're following the right path.
But i would think of two things:
1. They would not have implemented the encryption by hemselfes but more using open source (and therefore violating GPL license) because it's faster, and even more reliaable.
2. follows from 1.: i would rather search for a free blowfish implementation and take a closer look to the source of the decryption programm (reverse...) :-)
I don't know if you're following the right path.
But i would think of two things:
1. They would not have implemented the encryption by hemselfes but more using open source (and therefore violating GPL license) because it's faster, and even more reliaable.
2. follows from 1.: i would rather search for a free blowfish implementation and take a closer look to the source of the decryption programm (reverse...) :-)
Hey,
because this thread is nearly one year old, did you go on or didn't you spend more time in researching this issue?
Greetings,
- Patrick
because this thread is nearly one year old, did you go on or didn't you spend more time in researching this issue?
Greetings,
- Patrick
I sent an http-request as described, but forgot to remove the "otrkey"-part from the filename - and, guess what, the thing sent me the wrong hash (but marked the recording as "decoded")!!
So, what I guess from this is, that the returned string not only looks like a key, but also looks like a (e.g. md5-) hash.
I think the script just checks if you recorded that file, then returns a hash of the string it received.
Now the big question remains: how is that hash calculated?
So, what I guess from this is, that the returned string not only looks like a key, but also looks like a (e.g. md5-) hash.
I think the script just checks if you recorded that file, then returns a hash of the string it received.
Now the big question remains: how is that hash calculated?
hi there,
it seems, that otr changed the procedure. the link is now:
/quelle.php?code=[base64-encoded-code]&AA=[email]&ZZ=[yyymmdd]
mfg
tvj
it seems, that otr changed the procedure. the link is now:
/quelle.php?code=[base64-encoded-code]&AA=[email]&ZZ=[yyymmdd]
mfg
tvj
hey,
tvJunkie: are you sure that the "new" code-parameter is encoded with base64?
Do you have further informations how the decoding works?
tvJunkie: are you sure that the "new" code-parameter is encoded with base64?
Do you have further informations how the decoding works?
It seems that now, if u want to encode a file you don't own, the Server sends you: Error 4
I don't know if it plays a part in all this, but the otrdecoder also sends his own Agent with his requests.
I don't know if it plays a part in all this, but the otrdecoder also sends his own Agent with his requests.
Hm, I had a program that decoded the stuff,
essentially it is (was) blowfish + the file was folder over in the middle in 256 byt blocks:
0 n 1 n-1 2 n-2 ..... n/2
where n/2 could be a partial block which would be in plaintext then.
But I just discovered they (at least) changed the urls to get the key, so any hints there, and I post a decoding routine :-)
essentially it is (was) blowfish + the file was folder over in the middle in 256 byt blocks:
0 n 1 n-1 2 n-2 ..... n/2
where n/2 could be a partial block which would be in plaintext then.
But I just discovered they (at least) changed the urls to get the key, so any hints there, and I post a decoding routine :-)
I startet investigating this issue too. Here are my results so far:
1. Getting the key
=============
They still use /quelle.php?code=[code]&AA=[email]&ZZ=[yyyymmdd] for distributing the key.
In my case [code] was 683 bytes long, [yyyymmdd] could be either the day of the request or the day when the file was recorded. Recording date might make more sence.
The request (original client) returned a 684 byte long key (i doubt, that this is b64-encoded). A decoding-test on http://www.toastedspam.com/decode64 revealed nothing further, what reinforces the doubt in b64.
Three further requests (1x original client, 2x different client) to /quelle.php, using the same [code] as before, returned another three 684-byte-keys. These four keys have special characteristics. All keys have the same first 416 bytes. The following block of 268 Bytes (417 to 684) is different in every key, no matter which client was used. So I think the encryption does not depend on the used client.
May be, the numbers mentioned above, let someone conclude the encryption used.
2. Structure of .otrkey-files
===================
The encrypted file is always 522 bytes larger than the decrypted file. This 522-byte "header" contains the text "OTRKEYFILE" (10 byte) and a 512 byte key.
Comparison of 2 different otrkey-file headers revealed the following:
adress (dec) - length (dec) - content
000 - 010 - equal (text: "OTRKEYFILE")
010 - 024 - equal
034 - 016 - different
050 - 032 - equal
082 - 104 - different
186 - 008 - equal
194 - 521 - different (with some random matches)
so long
EK
1. Getting the key
=============
They still use /quelle.php?code=[code]&AA=[email]&ZZ=[yyyymmdd] for distributing the key.
In my case [code] was 683 bytes long, [yyyymmdd] could be either the day of the request or the day when the file was recorded. Recording date might make more sence.
The request (original client) returned a 684 byte long key (i doubt, that this is b64-encoded). A decoding-test on http://www.toastedspam.com/decode64 revealed nothing further, what reinforces the doubt in b64.
Three further requests (1x original client, 2x different client) to /quelle.php, using the same [code] as before, returned another three 684-byte-keys. These four keys have special characteristics. All keys have the same first 416 bytes. The following block of 268 Bytes (417 to 684) is different in every key, no matter which client was used. So I think the encryption does not depend on the used client.
May be, the numbers mentioned above, let someone conclude the encryption used.
2. Structure of .otrkey-files
===================
The encrypted file is always 522 bytes larger than the decrypted file. This 522-byte "header" contains the text "OTRKEYFILE" (10 byte) and a 512 byte key.
Comparison of 2 different otrkey-file headers revealed the following:
adress (dec) - length (dec) - content
000 - 010 - equal (text: "OTRKEYFILE")
010 - 024 - equal
034 - 016 - different
050 - 032 - equal
082 - 104 - different
186 - 008 - equal
194 - 521 - different (with some random matches)
so long
EK
About me
You can find my web page with links to my work as a journalist at https://hboeck.de/.
You may also find my newsletter about climate change and decarbonization technologies interesting.
Hanno Böck
mail: hanno@hboeck.de
Hanno on Mastodon
Impressum
You may also find my newsletter about climate change and decarbonization technologies interesting.
Hanno Böck
mail: hanno@hboeck.de
Hanno on Mastodon
Impressum
Creative Commons
Unless noted otherwise, all content is CC Zero / public domain
