Metro
22nd January 2007, 18:55
I'm going to summarize the current state of decrypting HD-DVDs at this time as I see it. Things seem to me to have become rather a jumble of different efforts. This morning I realized I don't know what would be the 'best' combination of programs and GUIs to use for a simple rip-and-watch, and if I'm confused it probably means that others are too.
In less than a month the original work by Muslix64 has virtually exploded into a bunch of tools aiming for the ultimate goal of being a one-click ripper. Many ingenious tricks have been posted by skilled people and the majority of posts have been both productive and instructive. The negative side is that we now have several GUIs, some linking to potentially transient URLs to grab keys. We have several methods of extracting keys, and we have no perfect tool because some do things that the others don't but in turn they lack features of the former. Meanwhile there is now a plethora of threads here which are in danger of losing focus and it's difficult to keep on top of all of them.
To compound the problem, there is a lack of comprehensive knowledge of the structure of the HD-DVD and the component parts of the navigation, control and object specifications. Given that the format is relatively new and the specs are to some extent restricted to paid-up members of the consortium which developed it, it's not surprising that we're having trouble picking it up. But we're getting there. It's been an exciting ride but it's a bit like a plant which has grown too quickly; maybe we need to prune it a little to ensure it grows in the direction we want.
In essence I believe that there are four parts to the effort to date:
- Further development of the original content decryption program including recoding in compiled languages;
- Perfecting automated extraction of keys from memory to feed the backup program;
- Automating the editing of XML-based XPL files to overcome navigaton and control problems in IME/UControl discs;
- The production of a friendly GUI to control the various components above.
Subsidiary to the above we now have lists of keys in more than one place on the internet and at this time there is talk of lists of hacked XPLs becoming available.
Finally we have a lot of promises and intentions to incorporate this feature or that function, and we also have Sourceforge repositories of code for people to collaborate.
In an ideal world each of the above components would be a building block which would have common hooks and specification so it could be plugged into the existing model and swapped out when changed. It shouldn't matter if you use Joe's key extractor or Fred's, or Mike's GUI or Mary's interface. In traditional programming, that would be achieved by having a high-level specification of the inputs and outputs of each block and each component author would stick to that structure.
With a loosely-coordinated effort such as we have here that's not so easy. We also have differing ideas on how to do things, mostly equally valid and brilliant in conception but not necessarily compatible. Combining two blocks into one may seem good, but it locks out the assimilated block for other developers. Fortunately we haven't seen much ego-polishing and everyone seems to want to pull together which is both a tribute to the great people working on the problem and the untiring efforts of the moderators.
What would be the best way of tying everything together? That's a difficult one, and as a newcomer to this forum I'm certainly not going to try to push my ideas onto others. (I can forgive you for thinking "Who the hell does this person think they are?") I'll just throw out a few thoughts and see if they strike any chords. I think maybe four discrete threads for the component parts, a fifth thread for the module input/output specification and a sixth for discussion of the structure of content packs and objects. I'd be inclined to want to see new threads for each, since we have become a bit sloppy in some of the existing discussion.
I want to stress that I'm not negating anyone's efforts to date, in fact it's been fantastic to watch the incredible progress as it's happened. Effort and achievement have been outstanding; I just think that we need more coordination from here if we're going to create a robust tool and be able to move with the inevitable game of tag that the content providers will play.
You would be entitled to wonder who I am, and I'll just say that I am an IT manager and I'm also a staff member of another forum which deals with using hardware and software in ways that the creators never intended. Anyway, if you want to carry on this discussion in this thread, the door is open. If you want to tell me to shut up and do something useful instead of sounding off, that's fine too. I just wanted to stimulate some thought and with luck nudge the effort towards our common goal; I hope this ramble has done that.
-s-
In less than a month the original work by Muslix64 has virtually exploded into a bunch of tools aiming for the ultimate goal of being a one-click ripper. Many ingenious tricks have been posted by skilled people and the majority of posts have been both productive and instructive. The negative side is that we now have several GUIs, some linking to potentially transient URLs to grab keys. We have several methods of extracting keys, and we have no perfect tool because some do things that the others don't but in turn they lack features of the former. Meanwhile there is now a plethora of threads here which are in danger of losing focus and it's difficult to keep on top of all of them.
To compound the problem, there is a lack of comprehensive knowledge of the structure of the HD-DVD and the component parts of the navigation, control and object specifications. Given that the format is relatively new and the specs are to some extent restricted to paid-up members of the consortium which developed it, it's not surprising that we're having trouble picking it up. But we're getting there. It's been an exciting ride but it's a bit like a plant which has grown too quickly; maybe we need to prune it a little to ensure it grows in the direction we want.
In essence I believe that there are four parts to the effort to date:
- Further development of the original content decryption program including recoding in compiled languages;
- Perfecting automated extraction of keys from memory to feed the backup program;
- Automating the editing of XML-based XPL files to overcome navigaton and control problems in IME/UControl discs;
- The production of a friendly GUI to control the various components above.
Subsidiary to the above we now have lists of keys in more than one place on the internet and at this time there is talk of lists of hacked XPLs becoming available.
Finally we have a lot of promises and intentions to incorporate this feature or that function, and we also have Sourceforge repositories of code for people to collaborate.
In an ideal world each of the above components would be a building block which would have common hooks and specification so it could be plugged into the existing model and swapped out when changed. It shouldn't matter if you use Joe's key extractor or Fred's, or Mike's GUI or Mary's interface. In traditional programming, that would be achieved by having a high-level specification of the inputs and outputs of each block and each component author would stick to that structure.
With a loosely-coordinated effort such as we have here that's not so easy. We also have differing ideas on how to do things, mostly equally valid and brilliant in conception but not necessarily compatible. Combining two blocks into one may seem good, but it locks out the assimilated block for other developers. Fortunately we haven't seen much ego-polishing and everyone seems to want to pull together which is both a tribute to the great people working on the problem and the untiring efforts of the moderators.
What would be the best way of tying everything together? That's a difficult one, and as a newcomer to this forum I'm certainly not going to try to push my ideas onto others. (I can forgive you for thinking "Who the hell does this person think they are?") I'll just throw out a few thoughts and see if they strike any chords. I think maybe four discrete threads for the component parts, a fifth thread for the module input/output specification and a sixth for discussion of the structure of content packs and objects. I'd be inclined to want to see new threads for each, since we have become a bit sloppy in some of the existing discussion.
I want to stress that I'm not negating anyone's efforts to date, in fact it's been fantastic to watch the incredible progress as it's happened. Effort and achievement have been outstanding; I just think that we need more coordination from here if we're going to create a robust tool and be able to move with the inevitable game of tag that the content providers will play.
You would be entitled to wonder who I am, and I'll just say that I am an IT manager and I'm also a staff member of another forum which deals with using hardware and software in ways that the creators never intended. Anyway, if you want to carry on this discussion in this thread, the door is open. If you want to tell me to shut up and do something useful instead of sounding off, that's fine too. I just wanted to stimulate some thought and with luck nudge the effort towards our common goal; I hope this ramble has done that.
-s-