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.
Related
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 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.....
I've got a crossdomain.xml file which allows SWFs running on only a certain few domains to download resources from my domain. However, one simple way around this is for a user to download the SWF to their local machine, and run it there (i.e. by double-clicking on it within Windows Explorer, not by running through http://localhost). It seems that when this happens, the crossdomain.xml file is ignored.
I understand that in my actionscript, I can do this:
if (Security.sandboxType.indexOf(Security.REMOTE) == -1)
// running locally - don't allow
However it is incredibly easy for someone to decompile the SWF and simply remove this line.
Is it possible to do something on the server side to stop a locally running SWF to download from my site? I tried checking the referrer but this field often isn't populated. Does anyone have any other ideas?
Thanks, Matt
You will never be able to completely prevent downloads by using crossdomain.xml. If the user just copies and pastes the requested URL to a resource into a blank browser window, the mechanism stops working. Also, the mechanism can be cheated by using a proxy. All it does is raise the bar a little, especially when someone tries to use an SWF video player to stream an FLV video hosted on your site.
If protecting your resources is worth the effort, you should consider adding some sort of authentication / authorization mechanism and/or encryption.
Double Clicking and running a SWF will usually only work if you have a stand alone player installed, otherwise it will open w/ a browser. Does Adobe distribute a stand alone player outside of Flash Pro? They didn't used to, although with Flash Platform Tools growing, they may do so now.
Nevertheless, I would expect most users will not have a stand alone player installed. In terms of security and protecting content, I suspect you're focusing on the wrong thing.
We have a web application where the users from whole world would upload there file at a same time. We want an effecient, robust upload system. Max file size would be 50 MB.
There would be atleast 1lac users uploading at same time.
Please suggest which is the better upload system, FTP or HTTP?
Currently we have http based upload where in we do get some errors like connection problem, session time out, time out error, etc...
Even suggest me for any 3rd party ftp upload tools if you come accross.
I will suggest you yo go with HTTP, because it is much favorable in terms of user convenience.
If you are having critical issues with Large file upload then Please have a look at Darren johnstone's Large File upload library for ASP.Net.
Still If you have to go with FTP then I will suggest you to go with using some Client Side reach technology which runs under browser like FLASH, JAVA Applets ( or might be SilverLight )
Depends on what you're doing.
every user I ever met knew how to use a browser, but the standard random user doesn't even have an FTP client installed. So usually HTTP uploads aren't really problematic. I wouldn't wanna upload huge files, but 50megs isn't that bad yet. If you want an FTP upload you probably would go for a java applet, so your users are guaranteed to have even the software needed to upload their files. Any PHP/WebFTP things will just run you into the same problems again.
Sometimes if I don't know if things I want to do work well, its a good time to look at how others are doing it. Gmail for example has a fabulous upload system. imageshack, millions and millions of users are uploading their stuff their, basically thats all the page does, and all of them use "normal" HTTP, with a little bit of JavaScript sugar to display the progress.
edit: here is an example with PHP: (although u seem to be using asp, it might still help)
http://www.devpro.it/upload_progress/
I have a Flex application I’m writing (Learning exercise) that I’d like to run of a network drive for many users to access. I’d like users to be able to save high scores on the network.
Users have read write to the network location it's on.
I don’t want to change anything on the computers that might use it (IE install AIR) or IE/Firefox settings. They are just default.
I don’t want to run a server (IE PHP)
Is there anyway to do it?
Cheers
Nope, not without AIR. And even then with difficulty. Flex runs within the context of the browser, and only has available to it the resources available to the browser (for obvious security reasons.)
Flash enjoys a unique position of corporate trust for reliability and safety, and they do everything possible to protect that position. So you're sandboxed.
The best I can think of is put together something that serves a URL and a common or custom read-write protocol - probably not trivial.
You will have to use a backend to access any of those resources. Eg, if you're using BlazeDS then you can just use Java to write to the network. You will have a server anyways to host your application.
You really want to use a backend technology for this. If you're dead set against it, Flash Player 10 can write files to the local filesystem. You could probably trick it to use a network resource by referencing it as a mapped drive or maybe even a named host.
http://livedocs.adobe.com/flex/3/langref/flash/net/FileReference.html#save()
You can also use the "load()" method of FileReference to read a local file into your Flex application.
I really don't recommend you write in an application using this but it looks like it could be done. The caveat here is that these actions can happen only if the user specifically chooses a location for a file: they need to select the file you want to load or choose the location where a file is saved.