Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Would something like Northcodes SWF studio be very secure - I jsut found out that (from their overview page) ... Protect Your Work: Are you worried about people extracting the files you bundle with your applications? File resources you bundle with your application can be encrypted using unbreakable 448-bit blowfish encryption. When combined with V3's secure loader your files will finally be protected from prying eyes. That means I can have external swf, flv's etc. and they will be encrypted using blowfsh encryption? That sounds good enough to me at least on a good deterrant level? Or am I being naive? Thanks, Nik On 4/16/07, Blumenthal, Peter <[EMAIL PROTECTED]> wrote: Thanks all for your responses (and apologies for my tardy reply!) Roy - that's a really interesting idea. I have a couple of follow up questions though please. Were you then loading those SWFs into Director, rather than using a loadMovie to load them into Flash? I assume so, because although I could use the BinaryIO xtra to rewrite the files to disc, then load them into Flash, that would of course expose the unmumged files while the application was running. Also, how difficult would it be for someone familiar with the SWF format to identify and strip those junk bits? I am thinking perhaps this *could* be a solution given AS3's binary socket capabilities... Hairy Dog - thanks for the pointer - am still reading through the archives - not really inspiring much confidence though I'm afraid :( Gustavo - no, Flash can't do this unfortunately, and in most cases it's a fairly trivial matter to work around Director's protected external casts too (well, as far as retrieving the assets goes anyway, not the code though). Coincidentally, Brazil is one of our target territories - if you can shed any more light on the level of protection against piracy in south America that would be both useful and interesting... I guess we still need to have some more internal discussions about how secure is secure enough, how much effort to protect is too much effort etc etc. Anyway, thanks for the input all. Pete 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. ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
not just yet, we are trying to get the go ahead for a demo first, do that, spec out the app fullyand approve the budget, so it might take a while. But I'll keep it in mind. What you have in mind is dongle-less, but protecting the swf from being decomplied? Or preventing it from being copyied tro say the hard disk? Thanks, NIk On 4/21/07, Michael Mudge <[EMAIL PROTECTED]> wrote: > And me ;) ! > > How would I connect such a dongle with the app I am trying to > preotect when I am using Director and / or Flash! I think I wasted a bit of your email blabbing about security. The reality is, you don't want a dongle, it just complicates things, and hardware is generally expensive. A decent and original licensing scheme ought to work fine. I think I can come up with some solutions for this... It may be a completely in-SWF solution, or a custom Projector program (.EXE that holds your .SWF). Is it worth my time to do some feasability testing? - Kipp ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
> And me ;) ! > > How would I connect such a dongle with the app I am trying to > preotect when I am using Director and / or Flash! I think I wasted a bit of your email blabbing about security. The reality is, you don't want a dongle, it just complicates things, and hardware is generally expensive. A decent and original licensing scheme ought to work fine. I think I can come up with some solutions for this... It may be a completely in-SWF solution, or a custom Projector program (.EXE that holds your .SWF). Is it worth my time to do some feasability testing? - Kipp ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
And me ;) ! How would I connect such a dongle with the app I am trying to preotect when I am using Director and / or Flash! Nik On 4/19/07, Laurie Jensen <[EMAIL PROTECTED]> wrote: Can you give me some guidance about vendors for low cost dongles please? Thanks. Laurie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Mudge Sent: Friday, 20 April 2007 4:51 AM To: [EMAIL PROTECTED]; flashcoders@chattyfig.figleaf.com Subject: RE: [Flashcoders] [semi-OT] - Preventing Software Piracy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Weyert de Boer > > > Genuine Dongles? What about dumping dongle data and then use a dongle > emulator? I'm glad you asked! =) Making a totally un-copyable dongle is actually pretty trivial. There are many USB microcontrollers that have Flash-ROM embedded in the chip, allowing you to "lock" the memory once its programmed -- no way to read it, even if you physically dismantle the circuit, except through the program's pre-programmed outputs. ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
Can you give me some guidance about vendors for low cost dongles please? Thanks. Laurie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Mudge Sent: Friday, 20 April 2007 4:51 AM To: [EMAIL PROTECTED]; flashcoders@chattyfig.figleaf.com Subject: RE: [Flashcoders] [semi-OT] - Preventing Software Piracy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Weyert de Boer > > > Genuine Dongles? What about dumping dongle data and then use a dongle > emulator? I'm glad you asked! =) Making a totally un-copyable dongle is actually pretty trivial. There are many USB microcontrollers that have Flash-ROM embedded in the chip, allowing you to "lock" the memory once its programmed -- no way to read it, even if you physically dismantle the circuit, except through the program's pre-programmed outputs. ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Weyert de Boer > > > Genuine Dongles? What about dumping dongle data and then use a dongle > emulator? I'm glad you asked! =) Making a totally un-copyable dongle is actually pretty trivial. There are many USB microcontrollers that have Flash-ROM embedded in the chip, allowing you to "lock" the memory once its programmed -- no way to read it, even if you physically dismantle the circuit, except through the program's pre-programmed outputs. Using a combination of book encryption and hashing algorithms, you can essentially have gigabytes of random data that can only be expressed through the microcontroller's pre-programmed USB outputs. Using a deliberate delay in the microcontroller, it could take 10 seconds to verify any one arbitrary key. Even if a straight year was spent downloading keys, the counterfeit would only have one answer for every 100 verifications. The PC then only stores one-way encrypted versions of the "answers", so even the PC does not know what the dongle will answer (making it impossible to steal keys from the PC). To see if the dongle answered correctly, the dongle's answer is encrypted using the same one-way encryption, and that is compared to the PC's already encrypted answers. - Kipp PS. There are ways of hacking these chips, involving slicing the top of the microchip off in a clean-room, running gold thread to the memory controller and reading the embedded memory directly. Haha. ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Yeh, but woudl that be an option (skills and software wise) to the average user, even to the average pirate or copier?? The ore I look into the issue, the more I am thinking of not really going beyond the deterrent stage, as anything beyond that becomes a 'project ' in itself, detracting budget and manpower from the core content, especially ni respect of the expected returns made one it. Nik On 4/18/07, Weyert de Boer <[EMAIL PROTECTED]> wrote: Genuine Dongles? What about dumping dongle data and then use a dongle emulator? Yours, Weyert ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Genuine Dongles? What about dumping dongle data and then use a dongle emulator? Yours, Weyert ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
If you want to verify that a genuine dongle is present, that's easy, but I have no idea how you would communicate with the dongle from ActionScript... You would almost definitely have to use an external program. I can think of a few Flash-drive-like dongle designs, but the development cost may be very near the development cost of your entire application. Honestly, the best thing might be to go with a commercial anti-piracy package. These packages have already had the cost distributed over multiple sales. You won't have to reinvent the wheel, and you will have a reasonable balance between price and effectiveness. Now that the topic has come up though, I just might persue making such a dongle... Hmm. - Kipp > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of nik crosina > Sent: Tuesday, April 17, 2007 4:52 PM > To: flashcoders@chattyfig.figleaf.com > Subject: Re: [Flashcoders] [semi-OT] - Preventing Software Piracy > > > Hi Kipp, > > that sounds exactly like the strategies recommended to me by > the Aladdin guys, and their manuals. And it also sounds > logical to me. The question to me is now whether I can tie a > dongle into actions script and then e.g. obfuscate the code > to a high enough degree that it would be above the pain level > of most crackers hackers and pirates. > > I do understand that it is impossible to create something > bullet proof, but some big pain in the ass is what (and I > guess most) developers are after. At least it prevents the > layman user from just making a copy for their colleague, etc. > > Nik C > > On 4/17/07, Michael Mudge <[EMAIL PROTECTED]> wrote: > > I can make a cheap, cryptographically secure USB or Serial > dongle no > > problem. > > > > However, the issue with any kind of software-based security is that > > once the software is on a client's machine, the client can > do whatever > > he wants with it; modify it not to use the dongle. > > > > But you CAN make it a serious pain in the ass. In > unmanaged languages > > like C, it is especially helpful to make the program inherently > > incapable of running without the dongle -- by using the dongle to > > perform some essential calculation that isn't in your > program, or by > > sending the dongle pieces of your program's code to > "verify" that it's > > been unaltered. Sometimes making a checksum of your own > code works, > > but then sometimes a hacker can use your own checksum algorithm to > > hack in a new checksum... > > > > ...so how far do you want to go with this? > > > > - Kipp > > > > > Hi Weyert, > > > > > > Can a dongle easily be circumvented then? > > > What's the best way of protection then, and do you know where I > > > would find a specialist in this? > > > > > > Thanks, > > > > > > Nik > > > > > > On 4/17/07, Weyert de Boer <[EMAIL PROTECTED]> wrote: > > > > Hi Nik, > > > > > > > > I have done research for my dad a while ago, and I came to the > > > > conclusion that it wasn't worth the effort $$$ wise. > > > > > Not sure whether that is applicable to your project, > > > Pete, but has > > > > > anyone ever used dongle (i.e. hardware) protection for their > > > > > projects? I am currently testing out HASP from Aladdin, > > > and does the > > > > > job so far (have not come very far yet in testing though). > > > > Yes, the problem with dongles is that it's quite hard to > > > > implement, right. Especially, I would like to advice > you not take > > > > any of the included examples or even consider build on > top of it. > > > > The examples are weak. Please rent some person who is > fully into > > > > the dongle and encryption. If not, it will be lost money. > > > > > > > > > What do you guys think about this kind of protection? Why > > > isn't it > > > > > used more often? > > > > Because it's a big investment to implement. > > > > > > > > Yours, > > > > Weyert de Boer > > > > > > > > ___ > > > > Flashcoders@chattyfig.figleaf.com > > > > To change your subscription options or search the archive: > > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > > > Brought to you by Fig Leaf Softwar
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hi Kipp, that sounds exactly like the strategies recommended to me by the Aladdin guys, and their manuals. And it also sounds logical to me. The question to me is now whether I can tie a dongle into actions script and then e.g. obfuscate the code to a high enough degree that it would be above the pain level of most crackers hackers and pirates. I do understand that it is impossible to create something bullet proof, but some big pain in the ass is what (and I guess most) developers are after. At least it prevents the layman user from just making a copy for their colleague, etc. Nik C On 4/17/07, Michael Mudge <[EMAIL PROTECTED]> wrote: I can make a cheap, cryptographically secure USB or Serial dongle no problem. However, the issue with any kind of software-based security is that once the software is on a client's machine, the client can do whatever he wants with it; modify it not to use the dongle. But you CAN make it a serious pain in the ass. In unmanaged languages like C, it is especially helpful to make the program inherently incapable of running without the dongle -- by using the dongle to perform some essential calculation that isn't in your program, or by sending the dongle pieces of your program's code to "verify" that it's been unaltered. Sometimes making a checksum of your own code works, but then sometimes a hacker can use your own checksum algorithm to hack in a new checksum... ...so how far do you want to go with this? - Kipp > Hi Weyert, > > Can a dongle easily be circumvented then? > What's the best way of protection then, and do you know where > I would find a specialist in this? > > Thanks, > > Nik > > On 4/17/07, Weyert de Boer <[EMAIL PROTECTED]> wrote: > > Hi Nik, > > > > I have done research for my dad a while ago, and I came to the > > conclusion that it wasn't worth the effort $$$ wise. > > > Not sure whether that is applicable to your project, > Pete, but has > > > anyone ever used dongle (i.e. hardware) protection for their > > > projects? I am currently testing out HASP from Aladdin, > and does the > > > job so far (have not come very far yet in testing though). > > Yes, the problem with dongles is that it's quite hard to implement, > > right. Especially, I would like to advice you not take any of the > > included examples or even consider build on top of it. The examples > > are weak. Please rent some person who is fully into the dongle and > > encryption. If not, it will be lost money. > > > > > What do you guys think about this kind of protection? Why > isn't it > > > used more often? > > Because it's a big investment to implement. > > > > Yours, > > Weyert de Boer > > > > ___ > > Flashcoders@chattyfig.figleaf.com > > 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 > > > > > -- > Nik C > ___ > Flashcoders@chattyfig.figleaf.com > 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 > ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
I can make a cheap, cryptographically secure USB or Serial dongle no problem. However, the issue with any kind of software-based security is that once the software is on a client's machine, the client can do whatever he wants with it; modify it not to use the dongle. But you CAN make it a serious pain in the ass. In unmanaged languages like C, it is especially helpful to make the program inherently incapable of running without the dongle -- by using the dongle to perform some essential calculation that isn't in your program, or by sending the dongle pieces of your program's code to "verify" that it's been unaltered. Sometimes making a checksum of your own code works, but then sometimes a hacker can use your own checksum algorithm to hack in a new checksum... ...so how far do you want to go with this? - Kipp > Hi Weyert, > > Can a dongle easily be circumvented then? > What's the best way of protection then, and do you know where > I would find a specialist in this? > > Thanks, > > Nik > > On 4/17/07, Weyert de Boer <[EMAIL PROTECTED]> wrote: > > Hi Nik, > > > > I have done research for my dad a while ago, and I came to the > > conclusion that it wasn't worth the effort $$$ wise. > > > Not sure whether that is applicable to your project, > Pete, but has > > > anyone ever used dongle (i.e. hardware) protection for their > > > projects? I am currently testing out HASP from Aladdin, > and does the > > > job so far (have not come very far yet in testing though). > > Yes, the problem with dongles is that it's quite hard to implement, > > right. Especially, I would like to advice you not take any of the > > included examples or even consider build on top of it. The examples > > are weak. Please rent some person who is fully into the dongle and > > encryption. If not, it will be lost money. > > > > > What do you guys think about this kind of protection? Why > isn't it > > > used more often? > > Because it's a big investment to implement. > > > > Yours, > > Weyert de Boer > > > > ___ > > Flashcoders@chattyfig.figleaf.com > > 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 > > > > > -- > Nik C > ___ > Flashcoders@chattyfig.figleaf.com > 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 > ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Nik, I missed the beginning of this thread (on vacation), so forgive me if I misunderstand the premises... but we've had a good experience using CrypKey Instant to "wrap" applications (http://www.crypkey.com/), which then require a software key to unlock for specific machine(s) only (it allows transfer of that license to another machine). CrypKey provides various solutions-- such as free (timed or usage) trials, network licensing, etc... We've had good experiences with tech support as well. The only gotcha with Flash is that you may have to embed it in a Director shell to wrap it. I forget why, but stand-alone Flash Projectors didn't work-- although maybe they do now (there's been a new release). --Dave The circumstances of the particular project I am quoting for would require the content to be almost exclusively off-line, diskbased, and to be used in a class room environment. So I explicitly do not want to rely in any way on authentiofication over on-line resources, as this will open up a minefield of getting it through various school, college and corporate fierwalls. Re the cost aspect , I think, this could be built into the courses as I imagine they would sell them much miore expdensively than the cost of a dongle (whcih averages out at about £20.00 (if memory serves correctly) Nik ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
I am aware that it's not a bad comment, Ron (Thanks for your thoughts on dongles, btw). I was interested in finding out what Ivan thought would be an alternative to trying to protect content. I am 'only' a developer working for various people and companies, but I am not sure at this point what the way forward is in situations like training and educational content? Is all of thi smade to be 'free' like music will be in a short while (few years, that is)? Also, what are content owners supposed to to 'in the meantime'? Nik On 4/17/07, Ron Wheeler <[EMAIL PROTECTED]> wrote: This is not a bad comment. What I gather that he is saying is that we are perhaps looking for a technical solution when we should be looking at the source of the need. If you believe that your customers will steal from you and try to make money from redistributing your product behind your back, then getting better customers is a better solution. If you think that potential customers will base their businesses on stolen goods, you probably should look at a different market or take the Microsoft approach "If they are going to steal software, I want them to steal mine" - Bill Gates If every potential customer steals your product and you come to dominate the market in your area, you will find lots of lawyers ready to help you collect your rightful license fees plus damages. In the meantime, make sure that your license agreement and contracts are clear. You are permitting use - not transferring ownership. The conditions under which they can use the product should be clear and the fact that they can not make copies or redistribute it (for free or for profit) should be in the license that they sign. Ron nik crosina wrote: > Hi Ivan, > > What you are saying is very easy to say if you don't feel the need to > actually comment on a possible solution. > > Without wanting to take this thread too OT - what is your suggesiton > to people / companies who have content which they invested > considerable amount ot time and money to create? > > Nik > > > On 4/17/07, Иван Дембицкий <[EMAIL PROTECTED]> wrote: >> Hello Peter, >> >> I think a problem in business idea. >> You can compare Microsoft and Google business idea. >> And? >> Do you like Microsoft direction? >> Everybody understand: it's yesterday's business principles. >> >> You need to change your mind for correlation with today's realities. >> Problem not in protection problems. >> Problem in business idea. >> >> IMHO. >> >> -- >> iv >> ___ >> Flashcoders@chattyfig.figleaf.com >> 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 >> > > > > > ___ > Flashcoders@chattyfig.figleaf.com > 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 ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
This is not a bad comment. What I gather that he is saying is that we are perhaps looking for a technical solution when we should be looking at the source of the need. If you believe that your customers will steal from you and try to make money from redistributing your product behind your back, then getting better customers is a better solution. If you think that potential customers will base their businesses on stolen goods, you probably should look at a different market or take the Microsoft approach "If they are going to steal software, I want them to steal mine" - Bill Gates If every potential customer steals your product and you come to dominate the market in your area, you will find lots of lawyers ready to help you collect your rightful license fees plus damages. In the meantime, make sure that your license agreement and contracts are clear. You are permitting use - not transferring ownership. The conditions under which they can use the product should be clear and the fact that they can not make copies or redistribute it (for free or for profit) should be in the license that they sign. Ron nik crosina wrote: Hi Ivan, What you are saying is very easy to say if you don't feel the need to actually comment on a possible solution. Without wanting to take this thread too OT - what is your suggesiton to people / companies who have content which they invested considerable amount ot time and money to create? Nik On 4/17/07, Иван Дембицкий <[EMAIL PROTECTED]> wrote: Hello Peter, I think a problem in business idea. You can compare Microsoft and Google business idea. And? Do you like Microsoft direction? Everybody understand: it's yesterday's business principles. You need to change your mind for correlation with today's realities. Problem not in protection problems. Problem in business idea. IMHO. -- iv ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Dongles would be pretty hard to control in a classroom. 1)They would disappear (practical jokes or wanting to run the software on different machines and not returning them, etc.). 2)The administration of many sets of dongles required to support different applications would make the Tech support people reject products that require them in a classroom setting. 3)Replacing lost dongles for legitimate customers would make the administrative burden for the software/courseware supplier much larger. Ron nik crosina wrote: The circumstances of the particular project I am quoting for would require the content to be almost exclusively off-line, diskbased, and to be used in a class room environment. So I explicitly do not want to rely in any way on authentiofication over on-line resources, as this will open up a minefield of getting it through various school, college and corporate fierwalls. Re the cost aspect , I think, this could be built into the courses as I imagine they would sell them much miore expdensively than the cost of a dongle (whcih averages out at about £20.00 (if memory serves correctly) Nik On 4/17/07, Danny Kodicek <[EMAIL PROTECTED]> wrote: > Hi Nik, > > I have done research for my dad a while ago, and I came to > the conclusion that it wasn't worth the effort $$$ wise. > > Not sure whether that is applicable to your project, Pete, but has > > anyone ever used dongle (i.e. hardware) protection for > their projects? > > I am currently testing out HASP from Aladdin, and does the > job so far > > (have not come very far yet in testing though). > Yes, the problem with dongles is that it's quite hard to > implement, right. > Especially, I would like to advice you not take any of the > included examples or even consider build on top of it. The > examples are weak. Please rent some person who is fully into > the dongle and encryption. If not, it will be lost money. > > > What do you guys think about this kind of protection? Why isn't it > > used more often? > Because it's a big investment to implement. Absolutely - distribution costs, particularly, especially as each dongle has to be unique. We've decided against using them for this reason. I think there are also cultural differences, though. Some of our international partners insist that dongle protection is the most common form in their countries. A lot depends on reliability of internet access for systems based on online activation (the only other method that seems genuinely secure). Danny ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
The circumstances of the particular project I am quoting for would require the content to be almost exclusively off-line, diskbased, and to be used in a class room environment. So I explicitly do not want to rely in any way on authentiofication over on-line resources, as this will open up a minefield of getting it through various school, college and corporate fierwalls. Re the cost aspect , I think, this could be built into the courses as I imagine they would sell them much miore expdensively than the cost of a dongle (whcih averages out at about £20.00 (if memory serves correctly) Nik On 4/17/07, Danny Kodicek <[EMAIL PROTECTED]> wrote: > Hi Nik, > > I have done research for my dad a while ago, and I came to > the conclusion that it wasn't worth the effort $$$ wise. > > Not sure whether that is applicable to your project, Pete, but has > > anyone ever used dongle (i.e. hardware) protection for > their projects? > > I am currently testing out HASP from Aladdin, and does the > job so far > > (have not come very far yet in testing though). > Yes, the problem with dongles is that it's quite hard to > implement, right. > Especially, I would like to advice you not take any of the > included examples or even consider build on top of it. The > examples are weak. Please rent some person who is fully into > the dongle and encryption. If not, it will be lost money. > > > What do you guys think about this kind of protection? Why isn't it > > used more often? > Because it's a big investment to implement. Absolutely - distribution costs, particularly, especially as each dongle has to be unique. We've decided against using them for this reason. I think there are also cultural differences, though. Some of our international partners insist that dongle protection is the most common form in their countries. A lot depends on reliability of internet access for systems based on online activation (the only other method that seems genuinely secure). Danny ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
> Hi Nik, > > I have done research for my dad a while ago, and I came to > the conclusion that it wasn't worth the effort $$$ wise. > > Not sure whether that is applicable to your project, Pete, but has > > anyone ever used dongle (i.e. hardware) protection for > their projects? > > I am currently testing out HASP from Aladdin, and does the > job so far > > (have not come very far yet in testing though). > Yes, the problem with dongles is that it's quite hard to > implement, right. > Especially, I would like to advice you not take any of the > included examples or even consider build on top of it. The > examples are weak. Please rent some person who is fully into > the dongle and encryption. If not, it will be lost money. > > > What do you guys think about this kind of protection? Why isn't it > > used more often? > Because it's a big investment to implement. Absolutely - distribution costs, particularly, especially as each dongle has to be unique. We've decided against using them for this reason. I think there are also cultural differences, though. Some of our international partners insist that dongle protection is the most common form in their countries. A lot depends on reliability of internet access for systems based on online activation (the only other method that seems genuinely secure). Danny ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hi Weyert, Can a dongle easily be circumvented then? What's the best way of protection then, and do you know where I would find a specialist in this? Thanks, Nik On 4/17/07, Weyert de Boer <[EMAIL PROTECTED]> wrote: Hi Nik, I have done research for my dad a while ago, and I came to the conclusion that it wasn't worth the effort $$$ wise. > Not sure whether that is applicable to your project, Pete, but has > anyone ever used dongle (i.e. hardware) protection for their projects? > I am currently testing out HASP from Aladdin, and does the job so far > (have not come very far yet in testing though). Yes, the problem with dongles is that it's quite hard to implement, right. Especially, I would like to advice you not take any of the included examples or even consider build on top of it. The examples are weak. Please rent some person who is fully into the dongle and encryption. If not, it will be lost money. > What do you guys think about this kind of protection? Why isn't it > used more often? Because it's a big investment to implement. Yours, Weyert de Boer ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hi Ivan, What you are saying is very easy to say if you don't feel the need to actually comment on a possible solution. Without wanting to take this thread too OT - what is your suggesiton to people / companies who have content which they invested considerable amount ot time and money to create? Nik On 4/17/07, Иван Дембицкий <[EMAIL PROTECTED]> wrote: Hello Peter, I think a problem in business idea. You can compare Microsoft and Google business idea. And? Do you like Microsoft direction? Everybody understand: it's yesterday's business principles. You need to change your mind for correlation with today's realities. Problem not in protection problems. Problem in business idea. IMHO. -- iv ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hello Peter, I think a problem in business idea. You can compare Microsoft and Google business idea. And? Do you like Microsoft direction? Everybody understand: it's yesterday's business principles. You need to change your mind for correlation with today's realities. Problem not in protection problems. Problem in business idea. IMHO. -- iv ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hi Nik, I have done research for my dad a while ago, and I came to the conclusion that it wasn't worth the effort $$$ wise. Not sure whether that is applicable to your project, Pete, but has anyone ever used dongle (i.e. hardware) protection for their projects? I am currently testing out HASP from Aladdin, and does the job so far (have not come very far yet in testing though). Yes, the problem with dongles is that it's quite hard to implement, right. Especially, I would like to advice you not take any of the included examples or even consider build on top of it. The examples are weak. Please rent some person who is fully into the dongle and encryption. If not, it will be lost money. What do you guys think about this kind of protection? Why isn't it used more often? Because it's a big investment to implement. Yours, Weyert de Boer ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
Hi, Not sure whether that is applicable to your project, Pete, but has anyone ever used dongle (i.e. hardware) protection for their projects? I am currently testing out HASP from Aladdin, and does the job so far (have not come very far yet in testing though). It does offer to build calls to the key into the functions of the software you are building, and I am in the process of finding out if that includes ActionScript as well. What do you guys think about this kind of protection? Why isn't it used more often? Nik On 4/16/07, Blumenthal, Peter <[EMAIL PROTECTED]> wrote: Thanks all for your responses (and apologies for my tardy reply!) Roy - that's a really interesting idea. I have a couple of follow up questions though please. Were you then loading those SWFs into Director, rather than using a loadMovie to load them into Flash? I assume so, because although I could use the BinaryIO xtra to rewrite the files to disc, then load them into Flash, that would of course expose the unmumged files while the application was running. Also, how difficult would it be for someone familiar with the SWF format to identify and strip those junk bits? I am thinking perhaps this *could* be a solution given AS3's binary socket capabilities... Hairy Dog - thanks for the pointer - am still reading through the archives - not really inspiring much confidence though I'm afraid :( Gustavo - no, Flash can't do this unfortunately, and in most cases it's a fairly trivial matter to work around Director's protected external casts too (well, as far as retrieving the assets goes anyway, not the code though). Coincidentally, Brazil is one of our target territories - if you can shed any more light on the level of protection against piracy in south America that would be both useful and interesting... I guess we still need to have some more internal discussions about how secure is secure enough, how much effort to protect is too much effort etc etc. Anyway, thanks for the input all. Pete 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. ___ Flashcoders@chattyfig.figleaf.com 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 -- Nik C ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
Thanks all for your responses (and apologies for my tardy reply!) Roy - that's a really interesting idea. I have a couple of follow up questions though please. Were you then loading those SWFs into Director, rather than using a loadMovie to load them into Flash? I assume so, because although I could use the BinaryIO xtra to rewrite the files to disc, then load them into Flash, that would of course expose the unmumged files while the application was running. Also, how difficult would it be for someone familiar with the SWF format to identify and strip those junk bits? I am thinking perhaps this *could* be a solution given AS3's binary socket capabilities... Hairy Dog - thanks for the pointer - am still reading through the archives - not really inspiring much confidence though I'm afraid :( Gustavo - no, Flash can't do this unfortunately, and in most cases it's a fairly trivial matter to work around Director's protected external casts too (well, as far as retrieving the assets goes anyway, not the code though). Coincidentally, Brazil is one of our target territories - if you can shed any more light on the level of protection against piracy in south America that would be both useful and interesting... I guess we still need to have some more internal discussions about how secure is secure enough, how much effort to protect is too much effort etc etc. Anyway, thanks for the input all. Pete 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. ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
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
RE: [Flashcoders] [semi-OT] - Preventing Software Piracy
This is a topic that's come up several times in the past on the Direct-L list. You might want to search the list archives at http://listserv.uark.edu/archives/direct-l.html ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
I don't know if this can help you out, but I'm little familiar with director and in south america I've seen that some developer put the libraries of the executable in external and locked. I don't know whether Flash can do it or not, but you would googled that issue...I hope this can help you. Regards Gustavo Duenas On Apr 11, 2007, at 12:53 PM, Blumenthal, Peter wrote: 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
Re: [Flashcoders] [semi-OT] - Preventing Software Piracy
At 5:53 PM +0100 4/11/07, Blumenthal, Peter wrote: >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. > Since you are running in Director, one technique I have used in the past which may work for you is to use the BinaryIO xtra and add some junk bytes to each .swf prior to distribution and strip out those bytes at runtime - basically munging the .swf so it won't playback (easily/at all) outside your set up. -- - Studio Site Updated! http://www.roypardi.com/ ___ Flashcoders@chattyfig.figleaf.com 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
[Flashcoders] [semi-OT] - Preventing Software Piracy
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. ___ Flashcoders@chattyfig.figleaf.com 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