Denny B


Has anyone used any JS obfuscation tools for their HD-DVDs Or are interested in using an JS obfuscation tool on their code

Denny B.

Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?


it can be bad , if the company XXX player can not play your YYY studio's disc


XXX has no way to contact YYY.

then XXX will probably have difficulty to debug or understand your disc.

offcourse they would have to hack into aca protection to access the contents.


Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?

Milo Winningham

Code obfuscation raises an interesting issue with AACS signing.

I have no experience with the AACS signing process yet, but the purpose is to verify that an application doesn't do anything malicious before allowing it to run, correct Will the AACS LA sign obfuscated code - code which cannot be read to understand what it does Or is the purpose of signing more to establish liability if a malicious application is released

Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?

Denny B

I apologize there are several different methods and processes for obfuscation. Some of which are blurred to also include encryption. Without the use of the eval method the ability to truly encrypt the js code is, as far as we can tell, nearly impossible in HDi. Unless of course you are using AACS. So with that in mind let us use the following definition for Obfuscation:

"to deliberately make something unclear or difficult to understand, by making use of unfamiliar terminology".

To give an example, most developers try and name their variables and objects to have a name that is relevant to its purpose. Such as a MainMenu object which has behavior and attributes related to a main menu. Using the definition above the object MainMenu would probably become something like a the methods inside the main menu would become a.a() a.b(), a.c(), etc.

This approach to obfuscation doesn¡¯t change the performance (at least not to our knowledge). So if you write a fast application and use the approach above you¡¯ll retain a fast application and vice versa if you write a poor performing application you¡¯ll still have a poor performing application.

Usually an approach like the one above also includes removal of comments as well but obviously it is hard to decipher that from the definition above so lets now include it in this discussion.

The reason I brought it up to this forum was because there will be a lot of discs out there that will not have AACS (the goal can be found here:, and I recommend reading the overview specification found on this page: and this page about licensing: Since there is a cost to add AACS there will be discs without it, at least initially and since code is being written that can easily be copied without AACS (along with all the other content) I am checking to see how the HD-DVD development community feels about this. Some communities embrace open code, others do not.

So I'm asking if an obfuscation tool would be beneficial There are plenty out there on the market already no need to build one.

Denny B.

Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?

Peter Torr - MSFT

Some observations / opinions :-)

  • AACS LA doesn't look at your content, nor do they directly sign it. You give them a hash of your file's hashes, and they sign that. So they will never look at the code to see if it is "good" or "bad"
  • AACS LA doesn't encrypt the content for you either; you get to decide what keys to use, and you do the encryption. The AACS process simply hides the keys for you
  • The computer can never tell if code is "good" or "bad" -- see the halting problem. It can only allow or disallow operations based on its policy.
  • An HD DVD player will refuse to load any file that it can detect has been tampered with, either because the hash / MAC doesn't match, because the AACS encapsulation has been removed, or because the decrypted content is invalid.
  • If you are using AACS, ECMAScript may be encrypted on disc, but it doesn't have to be.
  • There is no good way for code to be self-encrypting, even with eval. Sure, you can encrypt it, but you need to embed the keys inside the script itself, which defeats the purpose.
  • Obfuscation is a speed bump and won't really deter anyone who really wants to know what you are doing; since you can't change any of the built-in API names, it will be pretty obvious when you are doing the "interesting" stuff.
  • Obfuscated code is hard to debug (both by the original author or by a player vendor) and so will generally increase the chance that you have issues in the field
  • There are several obfuscation tools aready available, but having one integrated into a toolset as a final "mastering" process might be appreciated by some authors (especially if it can reconstitute the original script given some kind of name-mapping file, which would be useful for debuggin).

Of course, some people are very protective of their code and want to stop others from using it. The ability of any technical measure to prevent this is a function of the attacker's skill (or budget ;-) ). If it is easier to re-write the code than it is to steal it, they will re-write. Personally I hope there will be enough 'open' content on the web that it will always be easier to find a legit copy of a feature to use than to try and reverse-engineer someone else's, but we don't have critical mass right now like general AJAX coding does.

Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?


Denny has a good point. If one were to create something as robust as a "myspace" experience in HDi (which is coming!) I would want as much Obfuscation as possible, but I would also expect that others would reverse-engineer the script within 2-3 months and we would see "look alikes"...I wonder if AACS LA has any special way to "patent" your applications or if ISAN could help with this.

Re: HD DVD Interactivity Authoring Obfuscation: Good, Bad or Who Cares?

Denny B


Sounds like you are doing some really exciting stuff. Thanks for all the feed back. We agree with Peter¡¯s comments and we will be doing what we can to help include as many code samples as possible to help reduce the need to reverse engineer someone else¡¯s work to learn how to do things. We also feel that there is a need to provide some level obfuscation when a budget doesn't allow the author to buy a AACS license so they can use one of the possible spec compliant encryption methods to protect their work.


Denny B.