Hoi!
I've also stumbled across the avi files that you start and they claim that you can only play them in 3wPlayer. I decided to try and get the file to play in other video players and succeeded. It's pretty easy if you have a hex editor and know what to look for. For anyone that's interrested and has a bit of programming skills here's how I did it.
The first 100k bytes or so of the file are the black screen with the text. Everything after that is encrypted. If you know the structure of an AVI file (and how it looks like in a hex editor) and browse through the rest of the file you will notice that the basic structure is still there:
1) Some binary gibberish wich is the file header.
2) A lot of letters that repeat themselves - that would normally be a JUNK block.
3) More binary gibberish, wich is the actual audio and video data.
4) The last part of the file is alternating 4 bytes gibberish and 4 bytes readable letters - the keyframe index.
5) Some more repeating letters, the same ones as in 2).
So what encryption did they use and how to break it? At first I thought it would be ROT13 or ROT5 because of all the readable letters in the JUNK block. But then it dawned on me: Normally a JUNK block in an AVI file is binary zero bytes. The encryption they must have used is standrd exclusive or (XOR) with a short string, wich makes sense. It's really easy to implement, saves space since the function for encoding and decoding is the same and most importantly it's fast, wich it has to be when dealing with video.
What those morons who created that stupid player forgot, was that if you have a lot of the same bytes in the file you want to encrypt, the XOR key shines through.
The zero bytes from the JUNK block are the worst case, because then the key is in clear text. You can try it out with the windows calculator in scientific mode: Anything XOR 0 equals what you entered before.
The key in my file was 42 bytes long - whoever implemented this must have been a Douglas Adams fan *g*
All you have to do is check where the string repeats itself and count the bytes. Then go to where the string starts to repeat and count the length of the key backwards until you're sure you're after the unencrypted video part and before the encrypted header. Cut everything before that file offset or jump to this offset when reading the file and applying the XOR key, like I did.
Here's a quick perl hack to get you going:
CODE
# This is the key from the encrypted part in my file. Your's might be diffrent.
$key = 'UIERYQWORTWEHLKDNKDBISGLZNCBZCVNBADFIEYLJ' . chr(0);
@k = split //, $key;
open(IN, 'NAME_OF_YOUR_FILE.avi') or die $!;
binmode IN;
# Jump to the offset that you counted to
seek(IN, 100000, 0);
# Open a file for writing the decrypted data to
open(OUT, '>OUTPUT_FILE.avi');
binmode OUT;
truncate OUT, 0;
# read key length bytes, decrypt them and
# write them to the output file untill you reach
# the end of the file
while ( read(IN, $buffer, length($key)) ) {
$decrypted = '';
$i = 0;
foreach (split(//, $buffer)) {
$decrypted .= $_ ^ $k[$i];
$i++
}
print OUT $decrypted;
}
# Close both files
close OUT;
close IN;
I'm sure there's a more sophisticated solution to this and the code is kinda slow right now, but I wanted to watch the movie, not refactor code *g*
I'll try to come up with something more user friendly and let you know when I got it.
Of course the decrypted movie was not what was advertised... But it wasn't porn and I hadn't seen that one in quite some time, so it was not a complete loss.
Jun 10 2007, 04:39 PM
