If the code compiled with SWFEncrypt is truly not compilable or you consider that code secure, then it wouldn't take too much effort to make this reasonably secure... I'll offer a suggestion that doesn't really rely on it below.
Create a wrapper SWF which creates an AES tunnel to the server. All communication, even over SSL, would then be encrypted a second time. Depending on the amount of communication taking place, this could add a large CPU burden. The wrapper SWF could then download the real SWF (encrypted using a strong cipher, like AES) (see my blog, URL #2 below), after which it could be decrypted and run. The real SWF could also use AES to talk to the server, making network sniffing pointless. The risks could be mitigated pretty well: 1) The wrapper SWF could, if SWFEncrypt is considered secure, directly store the key used for the AES encryption. Or, it could be generated based on something like Merkle's Puzzles (see URL #1). 2) Since the wrapper SWF downloaded the real SWF, which was strongly encrypted, they would have to go to a LOT of effort to succeed: a) break the SWFEncrypt decryption b) figure out the AES encryption key (possibly generated dynamically) c) intercept the network traffic composing the encrypted SWF d) decrypt the strongly encrypted swf e) decrypt the SWFEncrypt encryption of the real SWF f) figure out yet another AES encryption key (possibly generated dynamically) ... (figure many more not-so-random things out) ... z) upload the new high score Furthermore, if the game has a fairly short running time in relation to the computational feasibility of the above steps, it would basically be impossible if the score is submitted using AES encryption or something similar. URLs: 1:http://en.wikipedia.org/wiki/Ralph_Merkle_puzzle_cryptographic_system 2:http://blogs.soph-ware.com/?p=14 I hope that helps a bit. --Kaleb --- In [email protected], "Michel Scoz" <[EMAIL PROTECTED]> wrote: > > About the client side (swf file), you could always try to encrypt the swf file with "SWF Encrypt"... people won't be able to decompile and use it as their own. Actually it will decompile but without any usable and/or compilable code. > > > > Of course this does not solve the network sniffer problem, but one of your concerns is gone. > > > > Cya, > > Michel. > > ________________________________ > > De: [email protected] [mailto:[EMAIL PROTECTED] Em nome de kenny14390 > Enviada em: terça-feira, 27 de maio de 2008 15:27 > Para: [email protected] > Assunto: [flexcoders] Re: The "High Score" Problem > > > > > > There is no such thing as Flash application security? > > > > Against what ? > > How much is the value of the prize ? > > Who is attacking you ? Why ? > > The prizes are pretty big, so there is a justified concern for > security. The "attackers" would be facebook users, so they will > usually be 18-25. > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , Tom Chiverton <tom.chiverton@> > wrote: > > > > On Tuesday 27 May 2008, kenny14390 wrote: > > > Is the simple conclusion that Flash applications are inherently > > > transparent? > > > > Yes, same as a HTML application, in a sense. This is the bane of > client/server > > computing, and *banks* haven't cracked it yet either. > > However, there are less people with the skills to decompile a Flex > app than a > > JavaScript one. But maybe all they need to do is sniff the network > traffic... > > > > > Does SSL patch any of these risks? > > > > No, because the user can configure an SSL proxy and see the plain > text of the > > session. But, again, less people will be able to do this. > > > > > There is no such thing as Flash application security? > > > > Against what ? > > How much is the value of the prize ? > > Who is attacking you ? Why ? > > > > Until you answer those questions, how can you evaluate any of the > various > > mitigation's ? > > For instance, if your attackers are all under 10 (because your app > is used in > > a closed environment, i.e. a school class room, and the login is > tied to the > > attendance list and O/S logged in user) then you probably don't need > to do > > anything else. > > > > > How can a "high score" problem be overcome? > > > > Some sort of CAPTCHA type test should prove there is a user sat at the > > computer, but I'm not aware of anyway to verify they're using your > client and > > not another one they built themselves. > > Given they can intercept your 'calculateChecksumOfYourself()' (or > whatever) > > and just send back the 'right' answer. > > > > A lot of the time, raising the bar fairly high (require login, SSL) is > > probably good enough. > > In your case, I'd probably want to require unique, verified email > address too. > > Maybe postal too as people tend to have fewer throw away postal > address' that > > actually work :-) > > > > -- > > Tom Chiverton > > > > **************************************************** > > > > This email is sent for and on behalf of Halliwells LLP. > > > > Halliwells LLP is a limited liability partnership registered in > England and Wales under registered number OC307980 whose registered > office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, > Manchester, M3 3EB. A list of members is available for inspection at > the registered office. Any reference to a partner in relation to > Halliwells LLP means a member of Halliwells LLP. Regulated by The > Solicitors Regulation Authority. > > > > CONFIDENTIALITY > > > > This email is intended only for the use of the addressee named above > and may be confidential or legally privileged. If you are not the > addressee you must not read it and must not use any information > contained in nor copy it nor inform any person other than Halliwells > LLP or the addressee of its existence or contents. If you have > received this email in error please delete it and notify Halliwells > LLP IT Department on 0870 365 2500. > > > > For more information about Halliwells LLP visit www.halliwells.com. > > >
