We've discovered that a Chinese site has figured out how to decrypt our SWFs, decompile them, then bypass any code which we put in to try to prevent the SWF from being run on any website other than ours.
As the Chinese programmers are gaining access to code, we need to figure out another way to stop them from running the SWF on their website -- at least during the limited exclusivity period on our site (usually a week or two).
I've proposed and so far our dev group has rejected making the SWF a simple client, thereby putting all of the game logic on our servers.
I've also proposed encrypting a SWF within an encrypted SWF, per this article -- http://www.veryinteractivepeople.com/?p=525 -- but based upon the comments, I don't think that it would help us.
Does anyone have any other suggestions?
You would have to find some key part of the logic (not just a verification code) and make it a WebService.
It should
not be easy to guess/replace
use small bandwidth
not be to critical for the reaction time
Related
I know I cannot access environnment variables directly in Flash.
My project is a local swf file, run from flash player and not through browser.
The goal is to protect the SWF to be played from an unauthorized PC.
(this is my client requirements).
My idea was to embed it into an EXE (made in Delphi for instance) as activeX.
I am not sure it is the best solution.
I think AIR is even more complex to be done.
Besides, how to forbid the access of the SWF directly ?
Maybe embedding the swf any way ?
Any suggestions, tips are welcome.
regards
I'm going to preface this by saying that I don't think there's a 100% way to stop unauthorised access - if there was, there'd be no such things as pirated copies of windows, or flash. The best you can do is make it hard to hack.
Some suggestions:
You can actually access environment variables, by calling an external process in AIR, using NativeProcess (this link has a quick writeup: http://www.tikalk.com/js/get-windows-environment-variables-air-application) - but it's trivial to hack the .bat or add the env var
You can implement your own serial key system and give out keys to legitimate users. It would ideally need to be verified by a server call
You can code a "phone-home" server call - the app won't work without it. How you identify your users is really up to you; you could try via IP, but it's not perfect
You could disable local execution (check out SecureSWF), and run it online, behind a login wall
You could disable local execution, and run it via an intranet, so people in a company can use it, but not the general public
Depending on your app, on startup, you can download necessary files (content) from the web. This can either necessitate a login, or you can block unauthorised IPs. This is how Ubisoft DRM works on some of their games.
In a similar vein, you can download other SWF files that contain the actual logic of your application. These SWFs would only be stored in memory, never saved to disk
With all of these, the app can eventually be hacked open and modified (e.g. your server-check code could be removed, so the phone-home never happens). At the very least, run your SWF through something like SecureSWF (http://www.kindi.com/) to obfusticate the code before any public release.
It all comes down to how much effort you want to put into tackling the issue. For all the of suggestions that involve the internet, if the network is down, you won't be able to use your app, which understandably will cause frustration. For all of the suggestions that don't involve the internet, you will never know if it was successful or not.
I've recently been slated with a task to port an existing Flash Player-base game to a desktop app for publication on the Steam platform. The Adobe AIR framework seems like a logical choice for distribution, especially given the latest updates in AIR 3. Given the fact that I'm relatively new to flash/flex development, I've read through a fair amount of AIR documentation on the Adobe site in order to gain a better understanding of what the task involves. In general, I think I have a decent idea of what needs to happen, but there are a couple of wrinkles that may affect if/how it is even possible to port to the AIR framework:
The AIR application will need to load the actual game client from an external server due to the quick turnaround time of the client development.
Since the AIR application will be deployed on Steam, I want to use the Captive Runtime bundling that's available in AIR 3.0, i.e. no need for the user to 'OK' a separate AIR installation.
Have minimal impact on code changes within the external SWF as I'm not the primary developer of the game.
My first priority is to figure out the best approach for loading an external game client SWF into an AIR application. Initially, I tried to utilize Loader.load(), but that resulted in the following exception:
SecurityError: Error #2070: Security sandbox violation: caller http://localhost/MyClient.swf cannot access Stage owned by app:/AS3_AIRTest.swf.
at flash.media::SoundMixer$/set soundTransform()
at com.company.client.sound::SFXManager$/load()
at global/client.util::loadEmbeddedSounds()
at MyClient()
The offending code is:
static public function load():void {
SoundMixer.soundTransform =
new SoundTransform(Client.Settings.PlaySFX ? 1 : 0);
}
Upon hitting this exception, I decided to read up a bit more on the AIR / Flash player security domains. I have a much clearer understanding of why the exception occurred, but I'm still uncertain what the best approach would be to load the SWF and not receive the exception above.
After scouring through numerous posts on various forums, I found that a number of developers use Loader.loadBytes() to bring the SWF into the application sandbox. From an ease of implementation standpoint, I can see why many choose to go that route; however, I'm not inclined to pursue that approach due the potential dangers to user systems in the event that the external server is compromised.
The second approach that I've read about is that I can utilize a sandbox script bridge, and write an interface to grant certain privileges to the external client SWF. I'm hesitant to go this route at the moment because the game client is fairly complex, and I'm not entirely certain how much access it will require of the stage via different flash APIs. I haven't written this approach off as it sounds like it may be the best bet, but it could potentially be a large endeavor and I want to have minimal impact on the client SWF.
The final approach I've read about is by making an HTML AIR application. My understanding (sketchy at best) is that a SWF loaded via HTML (I believe in a frame/iframe) will have its own stage. My line of thinking is that if the HTML app loads a main page, which in turn has an iframe with SWF embed of the game client, then the client SWF will load in a remote security sandbox and have access to its own stage. My hope is that the SWF would behave as it does in the Flash Player.
This leads me to the following questions:
Is my line of thinking correct about the HTML app?
Would the client SWF have access to its own stage and pretty much behave like it does in the Flash Player?
Can HTML-based AIR applications be bundled with the captive runtime?
Can I use a traditional flex application with HTMLLoader to accomplish the same goal or does it need to be a full-blown HTML app?
If HTMLLoader can be used, would I need to provide the sandbox script bridge meta tags in the iframe tag?
Any help would be very much appreciated at this point. It seems like there are a number of options available, but I'm not sure which path is the right one to pursue at this point in time.
Thank again.
Josh
You have already investigated a lot. I was going to mention Loader.loadBytes technique but you mentioned that it is not secure. Actually, you could take care of security if you knew the signed hashes of the SWFs that may be downloaded. I remember to have read this approach in a AIR team's manager's blog but I can't recollect the link at this time. Basically, the approach would work if you knew all of the SWFs before hand that could be downloaded, and then generated their signed-hashs and put those hashes in an XML which shipped with the initial AIR app. Then, the initial AIR app can download those SWFs, compare their signatures and load them in application sandbox if it matches up with shipped hashes etc.
(Long question with lots of points, but here goes)
You are correct that passing the Stage object through a script bridge isn't going to work. So, removing the code that accesses the stage and possibly using the script bridge to get the job done in each specific case would be necessary.
If you embed the SWF in an HTML page, it will indeed get its own stage. It does not matter whether this is an "HTML-based" AIR application or an ActionScript-based application that uses the HTMLLoader. (Really the two are the same thing.) You don't need an iframe for this. This sounds like the easiest approach, especially if you aren't adding many AIR-specific features.
For information on signing, see http://www.adobe.com/devnet/air/flex/quickstart/articles/xml_signatures.html
The other thing I'd look at, if you haven't already, is what facilities Steam offers for doing such updates. Is the turn around time for uploading a new project/update to Steam really greater than the time it would take to add this post-install update system to the app itself? (I hope you aren't in one of those Dilbertian situations where, on paper, it looks like you can save time by doing weird things. In my experience, miracles created by dragging sliders around in Microsoft Project (or the like) don't pan out.)
I'm making an asp.net web application which will run locally on IIS
for a single user
I don't want this user to access my application files (in the www root ) or bring another programmer and steal my code
I just want the user to have the ability to access the website only and
stop any programmer from knowing my source code
I heard about an USB security system called "Dongle" but can it be used in a situation like this ?
any Ideas ?
thanks in advance
The website is just running code, but like anything, once the user has it they can do what they like to it, whether you like it or not. That's why there is a multi-million {currency} industry around securing applications.
You could use dongles but they're expensive and not trivial to implement. As #volleyball said, obfuscation would slow down most people from decompiling your app. without odfucation any licensing or dongles could just be patched out of your code.
Your most secure route would be to not give it to them. It's a web app, host it. This may not of course not meet your requirements.
Simon
I have never heard of a web application that uses a dongle. This is normally reserved for regular windows apps; and even then it's falling out of vogue. Generally speaking some of the more expensive software packages still use them.
However, the cost of duplicating a dongle is pretty low. Combined with the fact that getting around such security is relatively easy anyway and you have a situation in which you really shouldn't bother.
As Simon said, if it's a web app host it. Otherwise obfuscate it.
If neither of those are possible, then I'd recommend you change your licensing deal with your client to include the possibility of them going elsewhere. Perhaps for an additional charge you'll give them a non-exclusive site license permitting them to do whatever they want with the code short of selling it or giving it to another entity.
did you look at obfuscators. They do a good job at encrypting code. 99% of the time your code cannot be reverse engineered. But if someone sits on your stolen code they can reverse engineer.. In the sense that ordinary people may not obfuscate it. If the person is very intellingent, he will not reverse engineer he will write better code.
I have a requirement by my client to be able to upload extremely large files.
I'm talking about 7 GB files. The website they are currently running on is a ASP.NET 4.0 app, so obviously the standard upload scheme for my web app is not going to work.
I'm tossing around multiple options trying to figure out what the best route to go would be.
One option I'm thinking about seeing if I can do would be to have a BitTorrent Uploader. The end users for this app will typically have the same file on hand, so the idea would be that an end user would go to the site, say that they wanted to upload a file. At that point, they would pick the file, and then the server would immediately mark that person as a seed for that file. Then, my web app would go to a preconfigured leech on our side, and instruct the leech to download the file. I would expect at some point during or after this process the torrent would do some magic to find other seeders on the client's network, or wherever, but that's the idea.
Is there any technology out there already that does this? Or am I describing something that I'm going to have to build from the ground up?
It doesn't sound like it's going to be easy to do this with BitTorrent. In order for BT to work, you need torrent files. In order to create a torrent file for a particular file, you need that file (the torrent file basically contains a hash of the file). In general for a torrent, you need a tracker. You could rely on a public one, but that could be a risky dependency. You could operate your own, but that has other challenges (for one, you'd have to make sure it's locked down so it doesn't become a free-for-all for all the latest movies, music & TV).
Assuming you have a tracker in place, you then need to coordinate the downloading of torrents. Your users are going to have to create the torrent files, which is an extra complicated step, then presumably upload them via usual HTTP methods. As well as getting the user to upload the torrent, you'd have to remind the user to start seeding the torrent in their client of choice. You'd then want to automatically begin leeching the torrent (again, security issue here - what if a user uploads a completely unrelated torrent for the latest episode of House?). Apart from the security problem, this is probably the easiest part - most torrent clients can be configured to watch a directory and automatically start downloading torrent files in that directory. Once you've started downloading, you have to make sure that the user continues seeding the torrent until you've completed, otherwise you'll be stuck with a useless partial file.
It could all work, but without a fair bit of customisation work it's going to be a convoluted process at best for your users, and quite possibly beyond them. Obviously I don't know your specific requirements, but I'd be looking at more traditional file transfer protocols, like FTP.....
Is it possible to upload a virus to a remote computer using a webform? If yes how do we prevent this from happening assuming we are limiting file types to just images?
The best way to avoid problems with user uploaded files of any kind is to have a command line virus scanner on the server, which you use to scan the files after upload. If the scanner result is positive, delete the file, record their IP address and inform the user.
It's a pain to setup first time but it's a life saver.
As I understand, you have a computer with an ASP.NET webserver that has a webform where you can upload files. And you are afraid that someone might upload a virus?
Well, unless you execute the file in some way, there is very little risk. It's just going to sit on your disk as a bunch of bytes.
Now, there is a very small chance that if you somehow process the image (say, resize it), and the processing software has a specific bug that the attacker knows about, then he could hijack the process with a carefully crafted image. But guess how big that risk is.
A few ways to reduce that risk even further are:
Keep the processing software up to date;
Run the processing software as a separate process with very few privileges (sandbox/virtual machine?), and kill it (and its child processes) if it takes too long;
Run the uploaded files through an up-to-date anti-virus software.
Don't use .NET/GDI/GDI+ processing functions (which are popular and people are trying to hack), but use some small 3rd party software (which nobody bothers to hack) that has all the necessary routines (image reading, writing and processing) re-implemented itself.
Although, honestly, I don't think the risk is large enough to worry about it.
First, note that it's unlikely that your server will be affected by a virus as it isn't going to be trying to "view" these files (unless you're doing something specific). So the main concern is to keep other users safe when they view these files.
If you're running the images through some sort of resize process (maybe to make them not-so-big so they download in a reasonable amount of time) then you are inherently creating a new image, which you can be fairly confident is free of viruses. This is a great way to ensure that the image is really an image and that it is free from malicious content.
you can't - even images may contain malware. http://news.cnet.com/JPEG-exploit-could-beat-antivirus-software/2100-7349_3-5388633.html
You could scan them with ClamAV after upload to ensure everything was ok. I think there are wrappers for most programming languages.
Yes, it is possible. But it relies on the remote computer (the server) to execute some part of the upload. This is relatively rare, but if you can not avoid executing the upload you should virus check the upload or run the image in a sandbox.
Obviously, your server could be vulnerable to some form of attack using the HTTP POST method - follow your chosen HTTP server's mailing list for any vulnerability like this.
I might be stating the obvious here, but you could scan all files with a virus checker when they have been uploaded?
just limiting filetype wont help much .. .
coz virus this days can infect any files .. doc to psd anything..
May used think about using AV for Server .. one such product can be found here
http://www.f-secure.com/en_EMEA/products/business/servers/anti-virus-for-servers/index.html
Just a thought. If possible, wouldn't a recompression/rescaling etc to the image corrupt the virus and make it non functional?