Hi List.
I'm interested in hearing people's thoughts on the issues surrounding
prevention of software piracy on Flash based applications, released on CD-ROM.
We have an existing product range that we are planning to roll out to
territories renowned for software piracy. The infrastructure is the same across
the range, with only the content changing, which allows us to quickly and
easily release new titles, a key factor in the product's success. However,
security wasn't a consideration when planning the original project architecture.
I know that nothing digital is completely safe from piracy ("Digital files
cannot be made uncopyable, any more than water can be made not wet" - Bruce
Schneier), and that this is even more of an issue for an open file format such
as SWF, but I am hoping to at least make it a bit more difficult.
Let me describe our setup:
- We have a Director executable, allowing OS level interactions to take place
where required, which acts as a shell for Flash content.
- The Flash application has a 'main movie', which loads an XML file which in
turn describes content 'tabs'.
- These tabs then provide different types of content (Book, Glossary etc).
- Each content type has it's functionality encapsulated in separate SWFs, which
in turn load further XML files which describe the content for each module.
- Some content module types will then load further Flash based content.
The main SWF will run fine out with the Director executable, except for the OS
level interactions, which aren't essential to the product's use. Furthermore,
each content module will also run independently of the executable and of the
main SWF.
The product must be able to run without an internet connection being present
(so no online authentication is possible).
So essentially:
>Director executable
>> Main Flash Movie & XML
>>> Flash functional 'sections' & XML
>>>> Flash content
We plan to protect the CD from simple copying using SecuROM (
http://www.securom.com/ ). However this protects only the executable, which
still leaves us vulnerable to the SWFs being copied and distributed along with
their dependent assets, which allows an unacceptable level of product usability.
Avenues we have considered focus around encrypting the XML, and / or protecting
the SWFs.
Approach A:
1. Encrypt the XML using a key and cipher.
2. Store the key in the (reasonably well protected) Director executable
3. Return key to SWFs in response to a call to a method in the Director
executable
4. Allow SWFs to decrypt XML after loading it.
Exploit:
1. Decompile one of the SWFs
2. Find the Director method name that returns the key
3. Roll your own SWF to retrieve key.
4. Using the retrieved key roll your own executable that will return this key
when required, thus circumnavigating the SecuROM protection (albeit with slight
loss of functionality)
Approach B:
1. Encrypt the XML using a key and cipher.
2. Store the key in the (reasonably well protected) Director executable
3. Reroute the loading of XML files through Director.
4. Decrypt in Director and pass XML back to SWFs
Exploit:
1. Decompile one of the SWFs
2. Find the Director method name loads, decrypts and returns XML
3. Roll your own SWF to retrieve all decrypted XML.
4. Replace encrypted XML with unencrypted.
4. Roll your own executable that will return this XML when required...
Approach C:
Protect the SWFs somehow, perhaps in conjunction with some encryption of the
XML. AFAIK the SWFs output from most protection / obfuscation applications are
fairly easy to decompile anyway. We have also considered wrapping the SWFs in a
Director DCR (again, AFAIK it is reasonably easy to decompile a Director DXR or
CXT too?), thought this will require a major code rewrite, and may not even be
possible given our current architecture.
Including the SWFs in the Director projector isn't an option, as these are of
course uncompressed and stored in a temporary location while the application is
running...
Ok, thanks for reading (assuming you got this far ;), apologies for the
massively long and probably OT post!
Answers on a postcard please to...
Pete
TIA
This email may contain confidential material. If you were not an
intended recipient, please notify the sender and delete all copies.
We may monitor email to and from our network.
This email was sent by a company within the corporate group owned
by Pearson plc, registered office at 80 Strand, London WC2R 0RL,
registered in England and Wales with company number 53723 and
VAT number GB 278 5371 21.
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
