dije la madre que los pario no puede ser estas jaladas en un torrent, bueno me puse a investigar un poco sobre el mentado 3wplayer y vi que efectivamente mi sospecha de que este player estaba infestado de spywarez y malawarez y dije bien me pondre a investigar que mierda pasa con esta chingadera....
bueno lo que descubri fue lo siguiente en un foro
  Jun 10 2007, 04:39 PM Post #1 | |
 Newbie Group: Members Posts: 16 Joined: 10-June 07 Member No.: 87,609  | 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 25 2007, 10:13 AM Post #8 | |
 Newbie Group: Members Posts: 1 Joined: 25-June 07 Member No.: 88,870 | codemonkey: i'v tryed that with a file i recently got.. from a source that i have never tested (theyr torrent, cause other bin from there are very very ok! probably some "user")! nice test for the first torrent there! seems "they"(who creat this critpty avi's) use same key for some time! the thing is, i did not had perl instaled and so, search for a perl script runner and got this: activeperl - check your OS binary the only change to your comment is: -with activeperl instaled, you only do "decode.pl ENCRYPTED_FILE.avi DECRYPTED_FILE.avi" on cmd, all in same dir. as avi's and .pl script, obviously! thanks for the light! RD |
bueno fuera de llo nromal el codigo funciono tra varios minutos de procesamiento y vi que la pelicuala era destino final 3 y en aleman dije puta (yo segun habia bajado transformers)pero luego encontre en el mismo foro una actualizacion del codigo que lo hace mucho mas rapido
CODE
# Turn of output buffer
$|++;
# The key for XOR decryption
my $key = 'UIERYQWORTWEHLKDNKDBISGLZNCBZCVNBADFIEYLJ' . chr(0);
my $times = 1;
print "Reading from \"$ARGV[0]\":\n";
$insize = -s $ARGV[0];
# Open the bogus AVI file
open(IN, $ARGV[0]) or die $!;
binmode IN;
# Read Header to check
read(IN, $buffer, 4);
if ($buffer ne 'RIFF') {
print " ERROR: \"$ARGV[0]\" is not an AVI\n";
close IN;
exit(1);
}
# Get Length of the unencrypted movie
read(IN, $buffer, 4);
$offset = unpack 'L', $buffer;
print " End of the unencrypted movie is at byte offset $offset\n";
# Jump to the read offset
seek(IN, $offset, 0);
# The next 4 or 8 Bytes seem to be either an unsinged long
# or an unsigned quad. This is another offset to jump
# over some filler bytes. Right now I can't really tell if
# it's 4 or 8 bytes, because I only have 1 file to test with.
# I assume it's a quad.
# low word
read(IN, $buffer, 4);
$offlo = unpack 'L', $buffer;
# high word
read(IN, $buffer, 4);
$offhi = unpack 'L', $buffer;
# Calculate offset
$offset = $offhi * 4294967296 + $offlo;
print " Offset after the unencrypted movie is $offset\n";
seek(IN, $offset, 0);
# Then there seem to be another 100 filler bytes
# with value 0xff. Jump over those too, to get
# to the offset where the real movie starts.
printf " Adding extra filler bytes, final offset is %s\n", $offset+100;
seek(IN, 100, 1);
# Update the size
$insize -= $offset+100;
# Open a file for writing the decrypted data to
print "Decrypting to \"$ARGV[1]\":\n";
open(OUT, ">$ARGV[1]");
binmode OUT;
truncate OUT, 0;
$bytes = 0;
$klen = length($key);
# 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, $klen) ) {
$buffer ^= $key;
print OUT $buffer;
$bytes += $klen;
# print the status
if ($times == 500)
{
printf "\r %d written (% .1f %%)", $bytes, ($bytes / $insize * 100);
$times=0;
}
++$times;
}
# Close both files
close OUT;
close IN;
print "\n\nDONE!\n";
bueno luchemos contra los putos antip2p
