arnezami

Wooow!

I think I just found the Volume ID of King Kong.

But I'm shocked! It doesn't appear to be anywhere near random as I expected it to be!! This could mean (just maybe) its guessable/computable...

If so then if we find the Media Key** we wouldn't have to use WinDVD to grab keys anymore . And the Media Key doesn't tell the AACS LA which software player was hacked so... This could also be the reason why AnyDVD supposedly can decrypt without the need for grabbing keys from WinDVD's memory which puzzled be deeply.

I don't want to get ahead of things but if this is true this could be very deadly for AACS. I wonder if this is due to some technical limitation. I will tell more later. Have to go to work now .

Oh yeah here it is:

Look at Section: 4.10.3.1 Volume Identifier in Introduction and Common Cryptographic Elements for more details.

Regards,

arnezami

PS. For some reason (even though i'm pretty sure this is the volumeid) I just can't believe it. But it really seems like the id is split in two parts of 64 bit: one part only 00's and 20's while the other part is a little more "random" (which to some degree would make sense seeing its also split in half on the disc).

** Later in this thread it became clear we need a Processing Key. But it amounts to basicly the same thing.

Update: The Media Key of King Kong has been found now .
Update 2: The Processing Key has been found too .

evdberg

According to section 2.3.3 of "HD DVD and DVD Pre-recorded Book" the above might indeed be the Volume ID.

struct VolumeID {
uchar MediaType; // 0x40
uchar Reserved;
uchar UniqueNumber[12];
uchar Reserved[2];
};

Reserved fields are always filled with 0x00.

You are also right about the ID split in 2 parts. One half is stored in the BCA (Burst Cutting Area) and the other half in the Control Data Zone (whatever that may be).

arnezami

Thanks evdberg. That confirms this is in fact the Volume ID.

Its incredible how not random this Volume ID is. I just figured out what these "unique" 6 bytes are:

Here is part of the entry in our volume key list:

Yep its a date (09/18/2006) and time (08:41) of the production. Although its done very weird since the hex is interpreted as decimals. But most importantly the Volume ID is not just guessable its even predictable! Incredible.

What does this mean?

This means that (especially for future software player updates) there would be no need for anyone to do a memdump/debug or anything. Only once per Media Key Block Version does the Media Key have to be extracted by one person in the world. If this is released everyone can decrypt any disc!!

This is opposed to having to design a reliable and working keyfinder program for a new version of a software player which may not be possible. And that would mean that everyone who would want to retrieve a volume key would have to be pretty savvy (using a real debugger etc) and this would limit the amount and speed of volume key discovery.

What the above (date/time) essentially does is vaporize the whole Host and Drive revocation scheme. Have they gone mad? Even if they do use proper unique Volume IDs from now on it will still be possible (using a very simple USB software sniffer I used) for less savvy people to get Volume IDs. And having Volume ID + Media Key equals to Volume Unique Keys . And the beauty is that a released Media Key doesn't reveal the (software) player that has been compromised.

To confirm the above it would be nice if we had some more Volume IDs. Maybe this date/time thing is only done by one distributer or something. Don't know. We have to figure it out. Since I only have one movie others would have to extract the Volume ID.

Finding the Volume ID

How did I find the Volume ID?

There are essentially two ways (now). I used the USB sniffer (with the xbox 360 HD DVD) because I knew I didn't have to bother with the (possibly obscured/wiped) memory of the software player.

1. Download USB sniffer 1.8 then unzip and start it.
2. Select the "USB Mass Storage Device" (I use the xbox 360 HD DVD drive) and click install.
3. Unplug the HD DVD drive (the usb cable) and replug it again. It will be recognized by windows and the sniffer starts logging.
4. Insert the Disc into the drive while the sniffer is.. well sniffing. Then start WinDVD and immediatly quit when the video (even the first black screen) starts. Then click 'Close' on the sniffer.
5. You now have a huge log file (60+ MB or something). Open it in WinHex (pressing F7 for ascii only) and search for the ascii string (not hex search!) "00000000: 00 22 00 00" including the spaces (but excluding the quotes of course ).
6. There was only one occurence of this in the whole file. So it has to be the Volume ID. Tata!

Btw: I used WinDVD but the above should also work for other players.

A different method (but less reliable I think) is to use WinDVD's memdump.

1. Open WinDVD's memdump in WinHex
2. Hex search (with WinHex) for 002200004000 or alternatively 0020202020200000. **
3. There you will (usally) find the Volume ID. But I'm not sure this will always work. There may be more than one occurance. You can check if the last 16 bytes (of the 36 beginning with 0022) are random since that would have to be the MAC. If its not random you haven't found it yet so you should go on searching until you do.

I'm going to try to extract the media key. I have no idea how difficult that will be (if at all). But if we have that we could make a program that decrypts all discs without needing any keys (apart from the one media key).

I hope we can find at least a few Volume IDs. If you retrieve one please also check the creation dates of the files/dirs on the disc and post it aswell.

Greetz,

arnezami

PS. Almost forgot: make sure you remove the last 16 bytes from the Volume ID log (which is the MAC) like I did in my first post. This is because in theory they might be able to track down your drive with that part... (you don't want that). The Volume ID itself is for everybody the same (with the same movie) so that won't reveal anything about yourself .

** See this post for more Blu-Ray instructions.

hajj_3

if this works this is freaking amazing, that was the only bad part, having to use a player to find the key in memory, wondered how long it would take someone to find it.

get cracking guys!

evdberg

Sorry for sounding a bit ignorant, but how does the Volume ID and MKB lead to the Volume Unique Key?

noclip

Manchurian Candidate Volume ID: 0531200601130020202020200000

Ishan

Nevermind ^_^

arnezami

I'm sorry for not explaining. The Media Key is a key resulting from the MKB (Media Key Block) and the Device keys. When combined with the Volume ID it gives the Volume Unique key.

Here is the part from the Pre-recorded Video Book section 3.3:

That basicly means that having a Volume ID (IDv) and a Media Key (Km) you can calculate the Volume Unique Key (Kvu).

Or to illustrate it (I removed the currently unused parts):



The red part is the hard part: getting the Media Key** (usually from a software player by debugging/memory snooping). But this only has to be done once per MKB and can be done by a pro.

The yellow part is what I described above: we either can (nearly) predict the Volume ID or we can get it via simple USB sniffing (the software player can't do much about that apart from bus encryption which is not implemented yet).

The blue part is the easiest: if we have the Volume ID (also called IDv) and the Media Key (Km) we can calculate the Volume Unique Key (Kvu) and then the Title Keys (Kt). This of course enables us to decrypt the content itself.

Hope that clarifies a bit.

Regards,

arnezami

** Later in this thread it became clear we need a Processing Key. But it amounts to basicly the same thing.

noclip

We can get the media keys now the same way muslix got the VUKs. We get a memory dump, take the first 16 bytes and the volume ID to decrypt, and see if the result is the VUK. If not, increment the offset by 1 and try again, it should be a very quick attack.

arnezami

Yes exactly. Or we can even use the Verify Media Key Record (3.2.5.4 in common aacs specs) on the disc. So we have two choices there. Feel free to try (I'm currently quite busy so I expect somebody else who is better at this to beat me to it ).

So far every key (title/volume key/volume id) has been in WinDVD's memory so I don't see why the Media Key wouldn't be in it...

evdberg

OK, I already wondered that I missed something, because I was sure we also need a device key. But if I am correct, PowerDVD keeps its device keys (although in encrypted form) in a file (001.fcl) ...

noclip

Who needs 'em? The only reason we would want a device key would be to decrypt the media key, which itself is already in memory.

evdberg

Reading the media key from memory is not really useful: in that case you can better grab the volume unique key as we do now ... the whole point of this exercise is that we want a method for decrypting without reading program memory, because this will most likely get harder in the future.

noclip

You're missing the point. With the media key we can decrypt all disks released so far.

evdberg

You are wrong. Please look at the above schematic. The media key is the result (decrypting?) of the MKB and the device key.

noclip

The device key decrypts the media key block to yield the media key. All the disks released so far use the same version of the media key block, thus the same media key.

arnezami

The point I am trying to make is that it should only be hard for one (or a few) people while it should be easy for many. Only that way will you get people to keep gathering volume unique keys. That means getting some crucial information (like the Media Key or even harder: an appropiate device key from a player's set of device keys) that can be used to decrypt discs. These discs also need specific information for decryption (the Volume ID) which can be obtained from outside the software player (by sniffing) thus making it impossible for the software player to make it harder and thus easier for the average Joes (who probably have many more movies than a few gurus have).

I do however (in principle) agree with you that it is not better (or worse) to go for the media in the memory of a player instead of the device keys. However its right now probably easier to retrieve the media key from memory than it is to extract a Device key (although technically we only need a process key but thats a different matter).

Btw I believe we should never (keep) releasing Device Keys. Its much better to release Media Keys. Unless somehow one version of an MKB can have multiple Media Keys (and as far as I understand that is not the "rule").

noclip

To go after a device key with known plaintext you must first have a known plaintext (the media key). We should focus on working our way up the chain of command from Volume to Media to Device to possibly (but unlikely) Root key.

madshi

What would stop studios from using a different media key for every disc?

noclip

The logistics of revocation. Essentially, every time a revocation happens a new MKB is issued which can't be decrypted by the revoked devices.

They may be able to change the MKB so that all current device keys are still valid, but then they risk an easy attack on their root key, which will have them running for the hills.

madshi

Ah - thanks!

arnezami

Thats not entirely accurate. Although I agree its probably easier to go after the Media Key right now.

Why is it not entirely accurate? Well to let a known plaintext work it doesn't have to involve just one encryption step (you do not have to know the Media Key in advance). Lets say we have a disc containing a MKB. In that MKB is a verify media key record. In essense this means: if you think you have found the media key using one of many possible Device Keys (which you try one by one using the memory dump as seed) then you can check if its valid. So yes you can go for Device Keys directly. But its a lot harder I think (because of the way the subset difference algo works).

The future will tell whether its easier to go for Device Keys (and then for Media Keys) or for Media Keys directly.

Ok. Lets go for this Media Key shall we?

And more Volume IDs are helpful too .

Regards,

arnezami

PS. And I'm not talking about variant keys. Those a (little) harder still...

noclip

Why would we ever need to go anywhere near variant keys?

arnezami

I was mostly referring to Volume and Media Variant Keys which you definitely need to decrypt all the content (otherwise you would miss like 1% or something and the video would basicly be broken at certain parts). This is the nastiest part of AACS in my opinion and I wonder when (and if) they will use it. Hopefully later than sooner.

noclip

I thought the variant keys were used so that AACS-LA could track down which device had been compromised, from small differences introduced into the video and audio streams.

evdberg

I just compared the MKBs of 2 disks and they are different. What makes you think they are all the same?

arnezami

Assuming thats the case we would indeed need Device Keys (well technically a Process Key would suffice and may be easier to obtain).

But the idea that one difficult to obtain key (in this case a Device/Process Key) would make it possible to decrypt discs using easier to obtain Volume IDs (or even guessable/computable). Therefore making a fairly independent decrypter (not needing too much updates) possible.

evdberg

A Process Key? Are you making that one up? As I said before, we need a device key to use the - easy to obtain - Volume ID. For the time being grabbing the VUK is the easiest in many ways ...

arnezami

Well its called a Processing Key (if you want to split hairs).

Anyway. Here is the quote from AACS common specs dealing with Processing Keys:

The Processing Key (and a C value) results in the Media Key. Its generally wise not to reveal your Device Keys themselves (although the last Subsidiary Device Key or the resulting Processing key is least damaging because they won't be able to determine which exact stored Device Keys you have and thus cannot revoke at once) unless they already know/guessed which device (= eg WinDVD player) you got it from.

Anyway. I think we should start thinking about what happens in a few months or so. They will probably revoke the current version of WinDVD and possibly other software players (just to be safe). The questions is: How are non technical people without too much hacking/programming experience (but with lots of new movies) gonna retrieve keys?

I believe a higher order key (Processing/Subsidiary Device Key/Media Key) could be very helpful for them to extract volume keys (assuming the simple mem search used right now with WinDVD won't work anymore for them). I think we are not disagreeing on that part. And I agree its very easy now (even without higher order keys) because of WinDVD. But thats the only thing now that allows many people to get VUKs. But thats not gonna last.

I guess the thought behind all this is: lets prepare for what will happens next.

Let me be straight: I don't want to replace something that is clearly working (extracting VUKs) but I want to add something in the context of probable future events.

Regards,

arnezami

arnezami

Concerning the differences in the MKBROM.AACS files. I am wondering which parts of the MKBROM.AACS file differ from movie to movie (or from disc to disc?).

The most important part (for us here) is the Verify Media Key Record. In my MKBROM.AACS its at position 74h (just before the Copyright text):

The bolded part is the actual Verification Data (for the Media Key).

I am now very curious if this part if different for other movies. Or if some movies have the same one. So if somebody could check. That would be great .

arnezami

PS. The start of the MKBROM file is probably the same for everyone: 10 00 00 0C 00 04 10 03 00 00 00 01. The last four bytes represent the version number.

jokin

Is this the right area?

arnezami

Thats a Volume ID indeed. And the unique 12 bytes are much more random in this case (although the last six sort of look like ascii characters: assuming you got this from WinHex: how does it show up in the Ascii part of WinHex?). What movie/distributer is this from?

I still see structure. Maybe we can figure out what it stands for (like the date/time thing in my example).

arnezami

PS. Its best to remove the MAC bytes like I just did for your own protection.

evdberg

But to calculate the processing key you still need the device key(s) ... and that's my whole point.

madshi

As far as I understand it, if someone manages to get hold of a device key and posts it on the internet, the AACS guys will come and revocate this device key. But if you post a processing key on the internet, the AACS guys will not know from which device key this processing key was calculated, so they cannot revoke the device key.

In other words posting a processing key on the internet allows many people to decrypt their HD DVD discs without having to search for VUKs first. At the same time the device key is still secret and so cannot be revoked.

Did I get this right?

arnezami

There are two ways to get Processing keys: using (1) Device Key(s) or (2) hacking them directly out of the software player. I'm not claiming you (or WinDVD) don't/doesn't need Device Keys to get the Media Key. The point is: you should only release the Processing Key or Last Sub Device key.

When I've got more time I may be able to explain this better. Personally I believe its much more likely we will only find one Device Key (while we should release a sub device key or processing key) when hacking a software player. But I can only explain that while also explaining the full subset difference algo.

arnezami

evdberg

Yes, you got it right, although "discs" should be "disc" (single). The processing key will just like the VUK be different for every disks ... and the way you have to search for the processing key is the same as for the VUK, so why bother ?

arnezami

I will go into this later. When I have more time.

But what I'm really interested in the the difference you mentioned between the MKBs. Are the versions different? Are the Verify Media Key Records different? Or is it for example the Copyright text (eg 2006 changed into 2007) which causes the signature to be completely different and it may therefore look like a quite different MKB (while the Media is still the same). I just don't know. I only have one disc. Please help us out here .

arnezami

evdberg

I double checked the files at the location you showed in post #30 (0x78 to 0x88), and they are different for all movies (and different from your values).

K40

In the MKBROM.AA.. of Serenity are these values:

00000070: xx xx xx xx 81 00 00 14 F0 5A D7 30 E4 1A DE 4E
00000080: B4 2A 11 61 0B DC C5 41 xx xx xx xx xx xx xx xx

If this is helping you i can post some more later

zeroprobe

disc not disks.

jokin

It is a memory dump I still had when I found the volume key for Apollo 13 from Universal studios.

Attached Images

	ss.jpg (28.1 KB, 10441 views)

evdberg

You mean disk ... disc is UK, disk US ... and since Silicon Valley is in the US ... disk is used with computer related round objects, disc is used for other round objects ... curious enough the CD is Compact Disc, most likely because the CD was not related to computers when it was invented.

The_ByteMaster

OFFTOPIC
Actually "Disc" is in the definition, just like you said
CD = Compact Disc
DVD = Digital Versatile Disc

Usually, "The Queen's English" is used for these matters.

The trailing D's are defined to mean "Disc". That is why "backing up your compact disc to your hard disk" looks funny but is correct in U.S. english.
/OFFTOPIC

ONTOPIC
I think it's great when we can find another way in, aside from using the volume unique keys. You bet software players are going to be hardened against these kinds of attacks. Snooping keys off a USB bus combined with knowledge of a "secret" device key might be the only way to go 2 years from now. For now there's no reason not to use the volume unique keys, but you have to be prepared when AACS LA is taking it to the next level.

arnezami

Does anybody have more Volume IDs of this form? Do you by any chance jokin?

In order to find a pattern or see what parts of the Volume IDs are different between different movies we need to have more Volume IDs. You can read the beginning of this thread to see how to extract Volume IDs. The more we have the better . Especially the one with no date/time (like the one from jokin). If we find a pattern we don't have to extract these Volume IDs anymore since we can then "guess" them (where "guessing" means: trying millions at a time using a computer). So even if we get a hint of a pattern that might be good enough.

Its also interesting to know that there are now two different versions.

First the ones with date/time in it:

- King Kong (USA) / 09-18-2006 / Universal studios / IME
- Manchurian Candidate (???) / 05-31-2006 / ??? / IME??

Then the one(s) with 6 ascii characters in it (and maybe two 24 bit numbers?) :

- Apollo 13 (???) / Universal studios / IME?? (ascii chars: WGHDVM - is this an Acronym?)

It would be good to have more of these (and there may be more groups) so we can maybe figure this out.

As for the different MKBs and Media Keys: I think its pretty clear that they are different on every disc. So we need to get a Processing Key (or sub Device keys) to be able to decrypt different discs**.

arnezami

** It can be proven whether or not one Processing Key can be used to decrypt every disc released so far: if the Explicit Subset-Difference Record is the same on every disc (I'm pretty sure it is) then the same Processing Key can be used. This Subset Record starts at position 0x0704 in my MKBROM.AACS file and the first 16 bytes are: 04000A1017000000011700800001. Please somebody check if its the same on at least two discs.

evdberg

You won't give up, won't you? But anyway, I checked 2 disks for you and guess what: the value starting at 0x704 is indeed the same! Please note that you only gave 14 bytes of data, but most likely the last 2 bytes are 1701.
I am not sure what you looking at. All I see is a repeating 5 bytes pattern in which the 2nd byte is increased by 1 every 2 patterns, and the 3rd byte is alternatively 0x00 and 0x80. It looks like counting 0, 0.5, 1, 1.5, 2, etc.

arnezami

Well you were right about the Media Keys being different. I assumed they wouldn't do that and I was wrong.

In this case though I know the Processing Key is able to decrypt multiple discs (which is what our aim is ) because of the algo used leads to the same position in the tree (because all the subsets are identical) with all these discs. And the position essentially determines which Processing Key you end up with. Its the C-values that make the Media Key different on every disc. These C-values are inside the Media Key Data Record which start at 0x1114 in my MKBROM.AACS file and starts with 0500xxxx followed by many C-values of 16 bytes each. If Media Keys are different then these C-values should be too. Just check it.

arnezami

blutach

Can we leave the spelling and grammar to another place please?

Regards

__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.

pacman2006

HDVM is the basic subset of graphics for menus and subtitles. According to a discussion here:
http://forums.appleinsider.com/archi...59917-p-5.html

It's just a guess. Also, Don't know about WG.

arnezami

Ok. Thanks. This definatly feels like its not random. And thats important.

It would be sweet if we could get another one of these Volume IDs extracted and see if the "WG HDVM" changes. If not than we wouldn't have to worry about that part being random/changable (this is important is you have to guess parts of the Volume ID: the more is fixed the better).

Ishan

I got the VID for Serenity (US), you're gonna laugh I guess

Wich of the 12 bytes "UniqueNumber" translate in ascii to :

I'm not kidding, check for yourself

mrazzido

hey

is volume id in blu-ray avaible is it useable? i can try to put my bluray burner in a usb case and sniff the usb port.

awhitehead

Title: Full Metal Jacket (US)
Studio: Warner Brothers
Modification Date: 4/17/2006 8:57 PM
UDF volume name: FULL_METAL_JACKET

USBsnoop log:
HEX to ASCII translates this to FULLMETALJAC



MKBROM.AACS:
Hope this helps!

Andy

Mug Funky

finding patterns in volume IDs is a red herring i suspect.

if there is a pattern, it would likely vary per replicator. there's no requirement for them to follow a pattern (or in fact to be well hidden), so it's no surprise they convey mundane information like title, date, etc instead of random numbers.

however, it does give us a bit more known plain-text. whether that helps us or not remains to be seen.

that's my 2 cents anyway...

__________________
sucking the life out of your videos since 2004

SBeaver

Could you explain what you mean by this?
Don't you mean that it gives us a bit of the key?

edit: and in any case, if the remainder of the key can't be guessed, bruteforced, or somehow calculated, it's of no use, is it?

arnezami

Thanks all!

This is indeed funny. A week ago I was really concerned about this Volume ID. I thought it would be very hard to get. But well...

I guess there are now 3 types of Volume IDs

1) With Date/Time
2) With 2x24bit? + 6 Captials WGHDVM (possibly fixed)
3) With the name of the movie!

I'm not sure how many replicators there are. But the person that fills in the Volume ID can do this after the Media Key/MKB are made and signed by the AACS LA (in their little "bunker"). So yes Replicators could do that. I'm curious who makes this decision and to what extend they can be "forced" to use a more random code. Well anyway. Maybe we can use barcodes to see if we can categorize them? I wonder if we have found all types used so far.

Of course they could change this Volume ID into a more random number. But as long as they don't we might aswell take advatage of it.

Does anybody have more of the WGHDVM type? The other 2 are pretty clear now .

Ooh yes! I would be very interested if this also works for Blu-Ray (according to the common specs it should). I'm also curious if they use a standardized system or something.

I would also be interested if this works with PowerDVD. Since it detects debuggers I wonder if it will detect sniffers too. If not then maybe we can devise a way to cloack it (the sniffer also uses a service so that may be hard to do).

And for those application/GUI programmers out there: since USB sniffer is open source maybe we can strip it from all things we don't need and make it a one-click type of application to retrieve the Volume ID only: "Volume ID Sniffer" . That could be very helpful in the future. Maybe we could also make one for directly connected IDE drives.

I'm going hunting for a Media and Processing Key .

Regards,

arnezami

jokin

Here are two more:

Batman Begins:



King Kong:

Mtz

sorry for offtopic. jokin, remove the .th from your screnshots links.

enjoy,
Mtz

jokin

Thanks.

Momotte

Is there something that I do not understand or is the VolumeID not enough to be able to perform decryption ?
All of this sniffing is interesting, but for us people who do not completely understand the math, how to we get to the VUK or to a key that allows us to perform the data decryption ?

thanks...

jokin

http://forum.doom9.org/showthread.php?t=120970

arnezami

You need a VUK to decrypt the data.

There are essentially two ways of getting the VUK:

1) Use jokin's key finder while WinDVD is playing the movie (this may not work in the future)
2) Get the Volume ID and use a (still to be found) general Processing/Device key to get the VUK. (as long as a general key will be found for each MKB version this will pretty much always work)

So in this thread we are talking about an alternative way of getting VUKs. But for now just use the keyfinder.

arnezami

Momotte

OK, you confirmed I was at least following a little. If you look at my first question, I was confused because I thought we could decrypt it only with the volumeid but it is not the case, we need more.

Thanks for your time,

Ishan

Works fine with PowerDVD 7.2 Ultra. And it seems there's no way to ununstall the service could be a problem in the future...

jkenzie

Another issue I had when I ran it with PowerDvd. Closing the service did not stop the log. It grew to 500K before I finally had to reboot with out the USB drive.

arnezami

Its good to hear PowerDVD works as well. There was a small possibility it would use bus encryption but clearly it doesn't.

It does indeed seem that the sniffer has some bugs in it. Those (at some point) have to be removed (and it has to be stripped of not required stuff) or we could use a different one (or an software IDE sniffer?).

Ishan

This sniffer is a bit buggy but works fine for me. I'll get some more VID when I'll get more HDDVD movies...

arnezami

Thanks to jokin .

Appollo 13:
Batman Begins:

Anybody see what these six numbers stand for? They are all pretty low (<= 64) so I have the feeling they mean something.

melakai

@arnezami

this is really minor, but i thought i should point out, there is an error in your apollo 13 hex2dec conversion. 06 should be 06, not 05 interesting to note that this one value is the same on both WGHDVM titles (aside from the WGHDVM values themselves)

arnezami

Thanks melakai

Some things I've noticed (when looking at these six numbers):

- The second number is very low (=< 6) and is the same for both
- The fourth number is also very low (<= 8)
- The sixth number is odd, all others are even
- The third number is somewhat higher than the last 5 numbers
- The first number has only 4's in it

It think we could use more of these to figure it out a little better.

SBeaver

I think it's just an acronym that they use one their discs, it doesn't even have to mean anything.
As long as you can still sniff them out anyway, why not try and break something else more important instead.
Try and get the device keys (or is it host keys?) from the software players to start with and then go on from there.
If all xbox players have the same device keys and you can manage to extract it, that would be a big step forward.

edit: btw, how many iterations would it take to bruteforce the discs with the WGHDVM?
Can't be that many, like (2^3)^6 possible values, that's no work at all.

arnezami

Ok. I'll try to concentrate on extracting keys. But if somebody or I succeeds then being able to calculate the Volume IDs would make it possible to decrypt all discs without sniffing or memdumps or anything. That would be nice .

SBeaver

If someone has a volume id decrypted and encrypted, and just say how to check if it's correct (that's done through hashing if I understand correctly) I could try fiddle around with it in some mathematics software and benchmark and try to refine the way to get the number with as few interations as possible while keeping it functional.
I'm doing a lot of this stuff at university right now and this would be a lot more interesting to try.
If the different manufacturers all use different naming schemes, it's likely they also have some other thing on their discs that is unique to only them which could make for a good detection system, unless the manufacturer differences is only between the different movie companies in which case you can just enter select the manufacturer in a list an the app selects the best way to bruteforce the key.
Since this key still isn't very useful maybe it doesn't matter but it's a fun exercise still.

edit: btw i made edit in above post

evdberg

Before people spend any more time on this ... as can be read from the documents and follows from the fact that you can 'sniff' the data from the USB, the Volume ID is exchanged unencrypted between the drive and the player. Hence getting hold of the Volume ID is not an issue ... please focus on the means to get from the Volume ID to the VUK ... just my 2 cents ...

arctor

I'm a little confused if this line of attack will be a massive gain.

Essentially it seems that by finding the device key you will be able to get the volume key directly without the need to do a memory dump while the player is playing it.

However if AACS take action against the compromised player they should start issuing new discs with a MKB file that does not contain the Media Key encrypted with the compromised player device key. Therefore the player could try and paly the media but it would not be able to decrypt it. Likewise any decryption utility using that device key would fail.

It got me thinking about what is in a Media Key Block file. Presumably AACS have generated all the device keys for all future players and when a new player is developed the AACS will release a key to that player. Also all discs (and all discs that have been made in the past) must have there media keys encrypted with the the total set of device keys. However the moment that a player is "revoked" then that device key is not used to encrypt future media keys.

In saying that it may take a long time for a key to get revoked. And the creation of a utility that can get the Volume Key without using a player would be nice as you don't need a VUK finder program. Don't want to discourage just want to check if my reasoning right

arnezami

There are several arguments to expand our capabilities to this approach:

• Retrieval of the Volume ID is standardized: a very specific response comes from a drive (even Blu-Ray I think) and happens outside the software player. They can do much less about preventing the sniffing than they can about hiding/removing the VUK in memory.
• The bulk of the future VUKs will have to be found by non-hackers (hackers do not own all discs) and therefore if its easy for most people (but hard for one) the spreading of VUKs can be fast. But if its (somewhat) easier for a hacker to only retrieve a VUK it will be harder for others since they do not know how to do extract VUKs like the hacker does. As an example: there are people now who do not have the Japanese version of WinDVD (but have for example PowerDVD) and they can't retrieve VUKs. But with retrieving volume ids its more straightforward: if you can play the disc you can get the volume id.
• A company who presses discs can change each batch (generating a new title key file and volume id) wihtout having to go to the AACS LA signing process. So its probably much easier for them to change VUKs than it is to change the Media Key on a disc. This way there could be many different VUKs for one movie but just one or a few Media Keys.
• When new discs are sold in the stores (with new subsets using different device keys) there should already be software players ready to play those discs. So there is always a window where a hacker can retrieve Device Keys (from the new or still non-revoked player) even when no new discs have been released yet! This could mean the decryption process may practically always work . This also means the hacker does not need to have the new discs to make them decryptable he just needs the new player.
• Releasing a Processing Key only will still not allow "them" to (clearly) identify the compromised player. This could strenghten WinDVD's legal position: this is a bussiness, WinDVD has a contract, and I guess they will only have to revoke their own player if the AACS LA can show/prove that their player (the device keys that is) was comprimised.
• And of course the more ways to get a volume key the better. I see this method as a additional attack vector. Its also a quite different technique.

Of course there are also problems with this technique:

• It may be really hard to get to the Processing/Device Keys. I've testing a bit and it doesn't look promising... yet .
• There is a possibility they are going to encrypt the bus to the drive. This can only be done with drives that are capable of bus encryption (and since the scheme isn't finished yet I suspect no drive right now can). I do not know if these bus encryption capable drives are/will be common or not.
• Even releasing a Processing Key releals a little bit about the player. But then again: they probably already know or can guess which player it is. I'm not sure how this works legally between Player company and AACS LA.

An even more ambitious approach would be to retrieve both the Processing Key and the Host private key (of a software player). That way we wouldn't even have to sniff Volume IDs anymore. But keep in mind that hosts are subject to revocation aswell and this is even harder for the hacker.

Hope I cleared it up a bit.

Regards,

arnezami

HyperHacker

6 bytes = 48 bits. 2^48 = 281,474,976,710,656. :-/ Hopefully I did that wrong. And that's assuming "WGHDVM\0\0" is always in the same place.

jokin, you blanked out some of the hex in your screenshot, but not the ASCII that goes with it. It wouldn't be difficult to figure out what the hex was from the ASCII, since this editor doesn't appear to ignore characters 00-1F and 7F-FF.

__________________
Because Moogles pwn.

jokin

Thanks for pointing that out. I am not sure why I am blanking it out. Someone said it was a MAC address but it is different for each disc I have done. Could someone explain that more. I have 3 more movies to do the dumps for.

SBeaver

ok i counted without the 06, but i still typed the wrong number.
Anyway, that, combined with patterns of the code, like all numbers are under 70 or something.

I googled to check and found this:

"Swiss-based Ph.D. Student Solves 48-bit
Key in RSA Data Security's Secret-Key Challenge; Search rate by 3,500 computers reaches 1.5 trillion keys per hour"

Note that this was from 1997

arnezami

Brute forcing these Volume IDs is not really an option (and not really required). But I believe we may be able to reduce it much further so it can be very easely guessed.

But we need more examples for that!

arctor

Thanks arnezami, thats a good answer and covers a lot of the things I didn't think of. Like the idea of finding the host private key. Maybe it will be easier to find as its bit bigger and may be stored very close in memory to the host public key (which should be viewable in the USB sniff.)

arnezami

I think I've found the Volume ID of a Blu-Ray disc. Well its from a memdump of WinDVD playing Lord of War.

Anyway here it is:

As you can see this is properly random and not at all guessable. I'm not sure if its possible the volume ID is encrypted here because then the 00 22 00 00 would probably have been encrypted too (although the protocol might not allow that). Not sure. My gut says its not encrypted. We can check this though if we have two dumps of the same disc (but the second dump after a restart of WinDVD) and compare the Volume IDs. They should be the same.

Because it has no 40 00 in it (like with HD DVDs) its much harder to find in a memdump but sniffing should be easier (searching for "00000000: 00 22 00 00"). But if you have a Blu-Ray burner and have a memdump of WinDVD you can try to hex search for 00 22 00 00. You will find many occurrences of that but only one with 32 random bytes behind it (= Volume ID + MAC). Thats the way I found it anyway (I mainly looked at the ascii part when pressing F3 so I could quickly see if it was followed by random bytes. I found it around Offset 4ABxxx but it could vary: between 300000 and 500000 would be my guess).

Something different. Regarding Device Keys. Could some people count the number of 0xx.fcl files their PowerDVD version has? (where xx are sequenced numbers) I suspect the newer versions have more of them. This is still a "feeling" but it could be interesting (its possible the new PowerDVD version got a different set of Device Keys already...)

Back to hunting

Regards,

arnezami

PS. I just found out my xbox 360 HD DVD is not capable of Bus Encryption . If you do a text search in your sniff log on "00000000: 00 72" you'll find two occurrances. The one with 01 (not 02) at the blue byte is the Drive Certificate. The byte right next to it should be 00 (red) if not then you're screwed otherwise you will always be able to sniff volume IDs . Here is mine:

Be careful with posting this stuff. If you are not you could reveal your drive id. Btw. if you have a PC drive and a memdump you may be able to find it using a hex search for 00720000 or 0100005C or 0101005C (but there are either lots or none of those so its hard).

PPS. Apparently WinDVD isn't capable either. Seems they really haven't implemented Bus Encryption yet.

jkenzie

My version has two. .000 and .001. What new version are you speaking of?

arnezami

Only two. Hmmm... So not 23 or 27. Interesting... Whats their size: roughly 630 bytes each?

I ask because a full set of Device Keys would have 31 + 30 + 29 + .. + .. + 1 =~ 500 Keys. So that would require 500 x 16 =~ 8000 bytes. Now they could do without certain Keys and only give 31 Keys (or even a little less) but that would mean that when two non-adjacent Players are revoked this PowerDVD version has to get new Keys by default. Because it wouldn't have keys for sub-trees. Hard to explain quickly.

Of course this is only relevant if these fcl files ineed contain the Device Keys that is .

Do you have Power DVD 6.5 or 7.1 or 7.2 installed?

jkenzie

Some interesting things about the 001.fcl file.
I noticed the original file date was 9/21/2006 from an install I had on a separate partition, but it had recently been modified in my main install. It showed a date of 2/5/2007.
The files were infact different, but not by much, it was actually smaller than the original.
Every time you put in a new movie it writes to the 001.fcl.

jkenzie

I have both 7.1 and 7.2 installed
000.fcl is 14KB
001.fcl is 19KB
both versions

arnezami

Hmm. Interesting. Thanks. A few questions:

- Are you sure its every time you put in a new movie? Not every time Power DVD gets new keys from the internet? Can you re-install and insert a new movie (for that new installation) and check whether the file(s) has/have changed? What movies do change it? Does it change only once or with every new movie?
- How many versions do you know of?
- Is 000.fcl still original?
- Is there any difference in behaviour between 7.1 and 7.2 in this matter?
- What do you mean by "not by much": how many bytes of difference are we talking about and where? Are you talking about a difference in the content or just the size? Are they different in content?

General question: does anybody have an (old) PowerDVD version that doesn't support HD/BD playback? Does it also have *.fcl files?

Thanks.

arnezami

PS. Its possible they have given a separate Key Set for BD. Which means two full sets would need roughly 16kb.
PPS. It might be possible Power DVD is removing Device Keys it knows it will never need (which it can see from the MKB on the first disc it sees) which might explain the "shrinking" here.

arnezami

I've got a related idea.

It just may be possible to create a perfect (but still encrypted) backup which is still playable. It would require re-encrypting the title key file and mac-ing it (with a new VUK) This new VUK would derive from the Volume ID of a re-writable (here lies the possible problem) and the unchanged Media Key (derived from the MKB).

To test if this even could work somebody with a HD DVD burner (and maybe a usb connected HD DVD drive) would have to try the following:

- Burn all (still encrypted) files to the new rewritable disc (do a bit-for-bit copy)
- Put it in a (preferably usb) HD DVD drive (and with usb turn on the sniffer) and start a software player (btw the movie won't play)
- See if the log contains a Volume ID (or if you don't have it usb connected and can't use the sniffer: if its in Jap WinDVD's memdump, see page 1 of this thread for instructions but leave out the 40 00 part like with Blu-Ray). If so it just might be possible...

Its entirely possible the disc is first somehow checked if its a pre-recorded one (eg. the drive missing the HRL in the lead-in area: or does the bit-for-bit copy that too? or something in the so called "system lead-in") which ends the story right away. But its worth a try I think.

arnezami

jkenzie

It's hard to tell when it is actually changing the file. This is the original file header:
If I overwrite my 001.fcl file with the original, as I play the first disc, it changes to this. With no other changes to the file.

My current version looks like this but ia also 1576 bytes smaller

arnezami

@jkenzie (or anybody else who has PowerDVD): could you try the following:

Open the 001.fcl file in WinHex (make a backup first) and see if there are any random stuff in it (I suspect the bulk is random is it?) Now change one byte in that area and try if Power DVD will play a movie. And try changing the file at different places (but only change at most one byte compared the the backup) and see what happens.

This could pin-point the exact position of the Device Keys used. But its possible there is some kind of checksum which disables this technique. If it works all the time then I suspect there are no Device Keys in it at all.

mrazzido

i have bd burner i made an complete image of a encrypted movie, burn bd yet on rw 30mins to go :-). i try windvd then what memdumb says then.

arnezami

If you can't find the Volume ID easely you may want to try to find the VUK using ape's hd-dvd volume key finder or use jokin's while WinDVD is running (there is also a possible timing issue: when WinDVD sees its a corrupt disc it may remove all information from memory or even crash, if that happens than just before that the dump has to be made). And see if it finds the VUK (which almost certainly is different from the one retrieved from the original disc)...

[edit] Sorry you need the bluray key finder of course... (but it checks for title/CPS keys so i'm not sure if this is a good test. Well maybe..)

mrazzido

i try to start the decrypted movie with windvd , windvd crached after push start. windvd try to load ( drive is working) the movie . then 2sec later crahed.

arnezami

I think there are several possibities here. One (relatively easy) way would be to install Visual C++ (just an example). After starting Visual C++ and then pushing the start button in WinDVD it (= MSDEV.exe which should be in memory) will intercept the crashing application and ask if you want to debug the application. At that moment (before clicking 'ok' on the pop-up) you can do a memdump of WinDVD.

There are probably many other ways (maybe somebody else can give suggestions) but this will most likely work fine.

Its interesing it actually crashes because that could mean we really fooled it (which is good news) .

mrazzido

powerdvd says this movie is aasc crypted cant play the movie.

arnezami

That sounds right. The movie is encrypted and the current volume ID (which is unknown for the moment) and Media Key won't produce a VUK that decrypts the Title Key file correctly.

In order to make this completely work we need to know (1) if the VUK is calculated at all (2) what that VUK is (3) encrypt the decrypted Title Key file with this new VUK (4) change the iso with the new Title Key file bytes (5) burn the new iso.

Keep in mind we are still at step 1 and 2.

But for the moment it appears the Software player notices that decrypting the Title keys (with the "strange" VUK) isn't working. Which is correct since we haven't changed the Title Key file yet.

In order to get any further we need to know if the Volume ID is extracted (which could be a sign that 1 is working) or extract the VUK directly (which sovles 1 and 2). But we can only do that with either a sniff log or a memdump.

It might be possible to do a memdump (or use the key finder) during the 2 seconds you mentioned. Its tricky though... The best way is to let the crash be intercepted.

mrazzido

just an idea ?? we need a "hd dvd or blu-ray emu" that powerdvd or windvd think a original disc is inside. then the programm has a databse with the keys. ripped from windvd memdump.

arnezami

Then its probably better to decrypt and play it (with an open source player). The gest of the above idea is that you might fool for example a PS3 or fool WinDVD/PowerDVD without the need of any software to be installed and without needing to decrypt the entire disc: a simple fix to the title key file in the iso would do the trick (if this works of course ). In principle you could even let a burning program do it on-the-fly for you.

Anyway maybe the posts (by mrazzido and me replying to him and my original idea-starter-post) about this subject (making an encrypted perfect copy) should be moved to separate thread because it really is a related idea. But has nothing much to do with trying to find Device/Processing/Media Keys and Volume IDs (sorry mods didn't really anticipate this).

jkenzie

If I change one byte at any point in the file the player will not initialize. I get the 1103 error.
I’ve watched the changes several times with several different disc’s inserted as first play. I always end up with a different .fcl file.
I don't think the changes are from am internet update, because the computer I'm testing this on has no connection.

arnezami

Ok. Thanks.

arnezami

After some (sometimes frustrating) work I found the Media Key of King Kong:



With that we are one step closer to finding a Processing Key .

Adub

Excellent job!
This is really great as it provides another manner of attack, thus preventing, well, "prevention".
Now, how the heck did you do it?

__________________
Flawless Media - Digitizing and Restoration
Zsmooth - Cross-platform smoothing for Vapoursynth
Zscene - Scene change detection for Vapoursynth
Old Site:Adubvideo

arnezami

Wooow. I think I did it .

Processing Key found!!!



More info later.

To be sure I need to confirm my finding. I need the following (from anybody with a HD DVD disc):

1) - Movie Title (not King Kong please )

2) - The Verify Media Key Record in the MKBROM.AACS file. It starts with 81 00 00 14 followed by the 16 byte Record. In my case this it at Offset 00000120h. Here is mine:
3) - The first C-Value in the MKBROM.AACS file (also called Media Key Data). It starts with 05 00 20 14 (the 20 14 could be different but is probably the same) followed by the first 16 byte C-Value. In my case this it at Offset 00004376h. Here is mine:
If you react quickly I can check if the Processing Key is really valid (for multiple discs).



Yeah I'm happy...

arnezami

hajj_3

im confused with all these keys lol. hopefully all the keys will be found on the disc soon, rather than in memory, so we can scan the disc and find all the keys.

Eeknay

1.) The Departed
2.) 3.) Hope that helps.

EDIT: Here's another disc just for kicks.

1.) Spy Game
2.) 3.)

arnezami

YES YES YES!! It works!

I'm going to take some rest now (I need it ). But will tell all later.

Here is the Processing Key which should work on all HD DVD discs (and maybe even Blu-Ray discs) released so far:

Save it. Store it.

Regards,

arnezami

PS. As explained before in order to get a VUK you now only need a Volume ID (which should be fairly easy to get or even to guess...).

hd1080p

Congrats everybody for the thrill of witnessing how DRM was defeated. February 11, 2007 is a day to be remembered.
I predict that movies will one day be liberated without DRM and we are all going to loose all the fun and excitement.
Fairuse wins!!


PS. As in LOR, this is the KEY(RING) to conquer all!!
Now, we have to find the processing key for blueray to help out HD-DVD market position. Movie studios may just stop releasing new movies on HD-DVDs. There should be a level playing field for the competing formats.

blutach

Nice work arnezami

Regards

__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.

arnezami

Thanks you all . Its been a pleasure.

As I can understand some of you are interested in how I retrieved the Media and Processing Keys. I will tell what i did.

Most of the time I spend studying the AACS papers. A good understanding of how things worked have helped me greatly in knowing what to find in the first place (and how to recognize something). I may write an explanation of (my understanding) of how AACS works in particular the subset-difference technique (which is by far the hardest to understand) at a later date if you guys want to.

But anyway. Since the moment I found the Volume ID (which was much simpler than I had thought) my thought was to try to find the Media Key. But after some discussion I thought it might be better to go directly for the Device Keys (bad mistake). After looking at files created and changed by software player and trying to recognize Device Keys in memory dumps I was starting to get worried a bit. I wasn't making any progress.

So I went back to my original idea: do a bottom-up approach. So first I tried to find the Media Key. One of the logical things to do even before that was to search for the Verify Media Key Record in memory. But it wasn't there. I then started to work on a little proggy that would scan a memdump and see everything as a Media Key: thus trying to verify it with the Verify Media Key Record. No luck.

This was frustrating: all kinds of information was in the memdump but not the Media Key (I sort of assumed/hoped it would). I made several memdumps at different moments but nada, nothing. After throwing it all away I remembered I still had a "corrupt" memdump from WinHex (it failed to finish it because WinHex said the memory had changed). It was really small compared to the others so I didn't have much hope. But when running it with my proggy: voila! I found it. Which finally gave me hope I was going in the right direction.

There were just two major problems left: how do you detect the Processing Key and if its not in memory how do you find it at all? Well since I now knew how things worked I knew the Processing Key had to be combined with a C-value to produce the Media Key. The problem was there are 513 C-values in the MKB! Searching the memory (several megabytes) for a Processing Key and assuming just one C-value would take minutes (if not hours depending on the size of the dump). So doing them all would take very long. And that while I didn't even know for sure there was a Processing Key in memory to begin with. I made a proggy that did this but using my favorite "corrupt" memdump I didn't find any Processing Key in the first megabyte (not for any C-value). It didn't look good.

But then I realized why I first didn't find the Media Key: it was removed from memory after the Volume ID was retrieved and the VUK calculated. I also saw that in my "corrupt" memdump the VUK, Vol ID, Media Key and the Title Key MAC were all closely clustered in memory: in the first 50kb (of the entire multi megabyte file!) but there were large empty parts around it. Almost as if it was cleaned up.

This gave me an idea: what I wanted to do is "record" all changes in this part of memory during startup of the movie. Hopefully I would catch something insteresting. In the end I did something a little more effiecient: I used the hd dvd vuk extractor (thanks ape!) and adapted it to slow down the software player (while scanning its memory continously) and at the very moment the Media Key (which I now knew: my bottom-up approach really paid off here) was detected it halted the player. I then made a memdump with WinHex. I now had the feeling I had something.

And I did. Not suprisingly the very first C-value was a hit. I then checked if everyting was correct, asked for confirmation and here we are.

Hope you enjoyed the ride. I'm thinking about a concept of proof proggy which does all the steps (from Processing Key to C-value to Media Key to Volume ID to VUK). It would require a Volume ID as input (which might be retrieved/guessed in another program or extension whatever). But the most important part is done: we have a Processing Key.

I'm also thinking about doing a full explanation of the AACS protection system (or at least the subset-difference technique). But only if there is any demand for it .

Regards,

arnezami

PS. For the keen observer: I'm not telling which player I used (well you can guess but you might guess wrong) to retrieve the Processing Key because I don't want to give the AACS LA any extra legal ammunition against any player company. Nothing was hacked, cracked or even reverse engineered btw: I only had to watch the "show" in my own memory. No debugger was used, no binaries changed.

jokin

Awesome awesome work.

And when you have time please explain the subset-difference technique.

Thanks again.

hd1080p

It is better than the real movie show. You are a genius!!
Please continue the work with blueray.

zeroprobe

great stuff. More write ups of the whole process would be greatly appreciated. More information the better.

How about one for bluray

arnezami

If somebody can give the same info Eeknay gave above (but for a Blu-Ray disc) I could see if this Processing Key works for Blu-Ray aswell.

pacman2006

Amazing work Arnezami!

I'm trying to understand the full aspect of having a processing key. Will this work for future discs too, or is this key also revokable?

hd1080p

Unfortunately, they (MPAA) can change the keys for future releases. At least now all current HD-DVD releases are deemed DRM free.
Fortunately, using ARNEZAMI's methodology, we can find them again using the particular player. Of course, they (player vendor) can change the way they implement the AACS DRM or even MPAA people can even change the AACS specs.

LokiHD

nice!

too funny..

mb2696

@arnezami - Amazing work!!! I'd really like to hear your in-depth take on AACS as well.

madshi

That sounds very nice!

But what happens if Volume IDs are created with real random numbers in the future? Will a Processing Key then still help?

Thanks!

buttfacepoop

arnezami,

thanks for your fantastic work.

i think by describing your exact method in finding the key, however, may lead people/MPAA to the exact player that is being used. perhaps when you in the future crack the player just post the key, no explanation?

SBeaver

I wasn't expecting this so soon.
You really did a great job, and whomever made the software player f**ked up serverely.

You shouldn't give up on the device keys though, we should steal all the keys they have.

btw is it possible to find the processing key with the usb sniffer, now that you know what the key is?
or is it moved over in encrypted form?
and finding it on the disk would be great, even if it's encrypted in several layers.

Anyway, you rock

tonyp12

So now that we have a Processing key,
How time consuming would it be to guess the VID (instead of USB sniffing)?

For example a decrypter that says
"please wait, I'm trying 2million possible keys"
And do that in about 30 seconds.

SBeaver

That would take some time to figure out.
A good start would be if we could get more sniffed volume IDs and unencrypted Volume IDs from different discs so we can figure out the patterns in the keys, if there are any.
If you can guess the key down to 6 unknown bytes by jst knowing the manufacturer then it's will work, but the more unknown bytes the more impossible it gets.
Finding a pattern is the only way i think, and it will work as long as the discs follow these patterns.
As soon as they fall outside the box then you have to go sniff again.

Ishan

I don't think there's any pattern, it seems it's different for each manufacturer.

SBeaver

well that is a patterns, there is just a few manufacturers making all (edit: most) the discs anyway so if we know patterns for each that is enough.
not a perfect solution though.

madshi

I rather think if the manufacturers/studios get notice of this thread they will probably make Volume IDs much more random than before. So I rather doubt that guessing will work in the future.

tonyp12

It probably will take 2 months before we start seeing
any changes in the values they use for Processing Key and VID.

It would be cool to have a HDDVD-decrypter that can decrypt
any disc from the top10 manufactures before this date without memdump/sniffing/keydb.cfg

After that it will be a cat and mouse game.

evdberg

Arnezami did great work, but he played out his cards much too soon ...

blutach

Rather poor choice of words. Nobody here is stealing anything - they are exercising their rights to play their legally bought material however they want to.

Regards

__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.

Adub

@evdberg
What exactly do you mean about playing his cards to soon? Are you saying he should have waited until the VUK memdump search method was retired?

What would you have done?

__________________
Flawless Media - Digitizing and Restoration
Zsmooth - Cross-platform smoothing for Vapoursynth
Zscene - Scene change detection for Vapoursynth
Old Site:Adubvideo

SBeaver

Well stealing is their definition of what people are doing.
Let's just say we are making copies of their keys just in case they lose them.

evdberg

Definitely !

I can understand his enthusiasm (it clearly showed from his posts), he was on to something and I know how that feels. But since the current method is still not counteracted, it's better to keep it to yourself ... don't bring other people on ideas ... well, the rabbit is out of the hat now, we will see what happens, but my guess is that a very promising method is wasted now.

xyz987