Skip navigation
Currently Being Moderated


Apr 29, 2009 2:49 AM

Has anyone any experience with VeriSign for Dir11 projectors? I need to sign my projector to get rid of the 'trust' messages that occur on XP sp2 and vista.


I have had no response from VeriSign themselves.

  • Currently Being Moderated
    Apr 29, 2009 3:57 AM   in reply to Xposure Interactive

    If signing the projector with the certificate was part of the publishing process, then it could work, but as it stands, there is no entry point in the publishing process to sign the projector. It cannot be done after the publishing process... I went throught this when building my RiEditor utility that allows Director developers to replace the icon and file/version information that shows up in Windows when viewing the Details or mousing over in Vista.

    During the publishing process, the projec32.skl file is used (it's really a bare-bones exe that when run on it's own looks for an .ini of the same name that contains a list of movies (.dir files) to play). Hence the error:

    Director Player Error
    Unable to load movie playlist. Does the .INI file exist? It must contain a section '[Movies]' with an entry 'Movie01=Pathname.dir'.


    Most processes that modify the projector such as a resource editor, utilities to replace the file/version information, signing certificate sol'ns - rip off the data from the end and leave you with essentially just projec32.skl file again... Director's compilation process does not produce a typical executable.


    The .dir you're publishing is compiled and appended to the end of the .skl file and some sort of offset or value is set somewhere telling the resulting .exe where the start of the info is when you double-click the projector to run it. I've looked at the file using a hex editor while building my RiEditor to deduce most of this information because some of what my RiEditor does is allow you to edit a projector, which means it rips off the data that's appended to the skl file (resulting in a perfect copy of the .skl file as mentioned above), writes some info to the .skl such as icon and version info and appends the code/asset data that was previously ripped off (of course, I saved it earlier in the process)...


    Anyways, that's probably more insight into how a projector is built than you wanted to know, but that's the real meat of it. I would like to get my hands on a signing certificate and the process to add it to an .exe to see what's going on... maybe I could build another utility that could sign you know of any free methods?

    Mark as:
  • Currently Being Moderated
    Apr 29, 2009 4:07 AM   in reply to Joshua Chunick

    btw, it's interesting and easy to test the whole .skl and .ini error thing:


    1. Locate the .skl file which would typically be here: C:\Program Files\Macromedia\Director MX 2004

    2. Make a copy of the .skl file and rename it to myproject.exe

    3. Move the .exe somewhere more convenient like your desktop

    4. Get a .dir file and place it on the desktop too. Let's assume the .dir's name is test.dir

    5. Create a new file and name it myproject.ini

    6. Edit the file with notepad and add this line:



    7. Save the .ini and launch myproject.exe


    It will load the test.dir file... This might be how you can get away with signing; with a setup such as this, you sign the myproject.exe... and you just use this stub projector method for all your projects.

    Mark as:
  • Currently Being Moderated
    Apr 29, 2009 5:54 AM   in reply to Xposure Interactive

    I haven't been able to 100% verify the method I mentioned will work to sign your project since the reports I've heard are all second hand and seesaw between you can and you cannot... You will have to add your Xtras in an Xtras folder in the same directory as your project files. Apparenly, if you're distributing for mac upper/lower case for the word 'xtras' is important... it's either all upper or all lower case (cannot remember)... other than that, you would use the basic file setup as I've outlined.


    btw, if you give this a go then post here whether you were successful or not in signing the renamed projec32.skl file...


    oh, and if you need to modify the icon in it before signing then you can use my Icon Resource - old version found here:


    you can try the new version if you also want to change the resource info too, but I haven't tested it on just the .skl file... only a published executable.

    Mark as:
  • Currently Being Moderated
    Apr 29, 2009 6:11 AM   in reply to Xposure Interactive

    You should be able to save your movies as either dcr or dxr and it should still work.  Theoretically.

    Mark as:
  • Currently Being Moderated
    Apr 29, 2009 6:58 AM   in reply to Xposure Interactive

    great to hear it worked... could you do me a favour and try renaming yor signed file back to projec32.skl, make a copy of the original in the Director folder and then replace the original with your signed projec32.skl and then try to publish a project... I wonder if that will work?

    Mark as:
  • Currently Being Moderated
    Apr 30, 2009 5:23 AM   in reply to Xposure Interactive

    Re: Update


    Thanks for the link. I used it, but then ran into a problem with signing so I did some more searching and found another link that also had a great walkthrough for personal signing: 5ef1ce3-a77d-4de9-82fb-c64ce1097345/


    Here are the steps by alexk59 (for anyone searching this in the future):


    Now I am documenting the complete list of commands and steps required to create and install code signing certificate. It WORKS. I used makecert and other tools included in Vista SDK (makecert.exe has file version 6.0.6000.16384, located in C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\), but I think all steps also should work with the same tools included in Visual Studio 2005.

    How to create and use code signing certificate on Vista computer (for testing purposes).

    1.      Create self-signed root certificate (MyRootCA), use “MYPASSWORD1” as a password (you will type it 3 times).

    makecert -n "CN=MyName Software Root Certificate Authority" -r -a sha1 -sv MyRootCA.pvk MyRootCA.cer -sr LocalMachine -ss MyName -sky signature

    2.      Create child certificate (MyCodeSigningCA) for code signing, create “MYPASSWORD2” as password for new certificate and when you are asked for Issuer Signature, type “MYPASSWORD1”.

    makecert -sv MyCodeSigningCA.pvk -iv MyRootCA.pvk -n "CN=MyName Software Code Signing CA" -ic MyRootCA.cer MyCodeSigningCA.cer

    3.      Create PFX key (use the password “MYPASSWORD2”).

    pvk2pfx.exe -pvk MyCodeSigningCA.pvk -spc MyCodeSigningCA.cer -pfx MyCodeSigningCA.pfx -po MYPASSWORD2

    4.      Optional step.

    cert2spc.exe MyCodeSigningCA.cer MyCodeSigningCA.spc

    5.      Use your PFX key to sign Test1.exe program.

    signtool sign /f MyCodeSigningCA.pfx /p MYPASSWORD2 /v /t Test1.exe

    6.      Install MyRootCA.cer  root certificate on Vista computer to LOCAL MACHINE store using Certificates MMC snap-in:

    a)      Run MMC.EXE on Vista computer (Start, Start Search, type mmc.exe, press Enter). MMC console window appears.

    b)      Choose “File”, “Add/Remove Snap-in” menu command,  the list of snap-ins appears, choose Certificates, choose Add command. The “Certificates snap-in” dialog appears, choose [x]”Computer account” radio button.  “Select computer” dialog appears, choose “Local computer”.

    c)      The “Certificates (Local computer)” snap-in node appears in MMC left window.

    Select “Certificates (Local computer)”-“Trusted Root Certification Authorities” – “Certificates” node.

    Choose “All Tasks” – “Import…” context menu command on “Certificates” node.

    d)      Import your MyRootCA.cer certificate.

    “MyName Software Root Certificate Authority” will appear in the Trusted Root Certification Authorities certificates list, in “Issued To” and “Issued By” columns.

    e)      Close MMC.

    Run Test1.exe. Vista should detect the publisher of this EXE file as “MyName Software Code Signing CA”.



    So, I found that the signing process added 2794 bytes to my executable. That got me thinking that maybe if I could then cut that amount from the resource part of the .exe (projec32.skl file which is the first 81920 bytes) where it wasn't needed I could have the same sized file. There's some padding at the end of the projec32.skl file for both D10 and D11.5, but not enough. So, I padded it with some more 0 bytes and then threw it back into my Director folder... published again and the published test.exe file worked fine, as I knew it would because the offset to the data that was compiled was calculated properly during publishing. Next, I proceeded to sign a copy of the test.exe file that I renamed test1.exe... then, I signed test1.exe and that process worked, but as expected, it broke the executable and I was getting the message we've all seen... lastly, since the signing process seems to write to the resource part of the exe (the projec32.skl part of the exe) I used D11.5's fileIO and bytearray to seek to position 81920 and cut out the extra 2794 bytes of padding that I had added within the resource. Not only would this have broken the digital signature - which I didn't realize at the time - it seemed to also break the executable to the point that it now was not recognized as a legit win32 executable... of course, it was very late so I probably didn't take some aspect of it into consideration or messed something up with the new bytearray methods since they're a bit unfamiliar... but, in the end, as I've mentioned, it probably will break the singing, even if I can get the exe to work again... So, in the end, the signing process would need to be included by Adobe into the publishing process so that they could change that elusive offset value in order for the exe to not break.

    Mark as:
  • Currently Being Moderated
    May 8, 2009 4:19 PM   in reply to Xposure Interactive

    because you're making a stub projector that's running a .dir or protected .dxr file, you need to include the .dll's found in the Director installation folder. Here's the info:


    In D10, the DLL's are:
    projec32.skl -- of course, you won't need this file.

    In D11, there are two additional DLL's:


    That should do the trick.

    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 1:46 PM   in reply to Xposure Interactive

    just curious, what did you name your .exe?

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points