I will develop a game with server/client pattern. Client and server communicated through TCP socket. And for the server's data security, we encrypted our data stream with some key.
But here's the problem, the actionscript code be easily decompiled with tools. So the key is NOT safe even after obfuscation. You can still restore it if you like to spend more time.
I also checked FlashCC project but it will cost us when combined stage3d.
So is there anyway to hide my key?
Use asymmetric encryption TLS or SSL over socket. Although flash player 11 has native SecureSocket it has some problems, so I recommend you TLSSocket from as3cryptolib (here is the fork of the last version of official as3crypto lib with some critical fixes from the issues list)
I've come to the conclusion that you can't have a 100% unbreakable swf. The only thing you can do is to multiply the obstacles to discourage the hacker.
As said in a comment, the safest method would be to have the whole game logic on the server and let the server compute the scores (or other sensitive data) itself. But depending on the type of game, this may be a really stupid idea.
Related
I am newbie in using Streaming Server. we are evaluating EvoStream Media Server to stream HLS stream with AES128 encryption.
I have few queries on AES 128. I have search through google but no luck
When doing HLS with VOD(Video on Demand) , Evostream creates chunks of segments along with m3u8 index file that contains all information including key and IV vectors.
#EXT-X-KEY:METHOD=AES-128,URI="2015-06-25T11-20-18.key",IV=0x0360f11b211ef025d7f72c41d58e0a2d
My question if when i play this file in html5 media player and debug it using F12, i can easily get the key and IV used to encrypt the file. Then what is kind of security AES provide if anyone can get those key and IV vector to decrypt the data.
Please any one have some knowledge over it, please share ...
The key seems to be in yet another file:
URI="2015-06-25T11-20-18.key"
2015-06-25T11-20-18.key is only a reference to the key, not the key itself.
So you need to control access to the file and only make it available to persons that are allowed to play the video.
The answer to your question is that HLS with AES-128 provides transport security making it difficult for someone to capture your content in a man-in-the-middle scenario. It doesn't provide DRM.
You are supposed to change the keys every 3-4 hours and the IV every 50 Mb of data and serve the keys over HTTPS and not plain HTTP.
See Serving Key Files Securely Over HTTPS on the Apple Developer site.
The first thing, that you have to keep in mind when dealing with content protection, is the fact that there is no perfect solution. There is no solution to guarantee you that only the audiences that you intended will be able to watch the video. All the protection schemes make it harder for the others to steal it but not impossible. Here are some of your options:
AES-128 encryption - you have to take special care to protect the key. Once the key "leaks" then anyone will be able to decode the video with some effort. The advantage is that's this method is simple and supported by the multitude of players.
SAMPLE-AES encryption - again you have to take care of the key. But even if it "leaks" one would need a specialized software to decode the video as it's not trivial. The disadvantage is that not all players support this method.
use DRM - DRM solutions are very expensive and require effort for integration and specialized players. But they provide the most protection.
There is no silver bullet. It depends on you needs and the level of protection you need. Don't forget that after all even the most advanced encryption scheme is not protected against simple things like screen capturing for example.
In normal case or a general use case
1. You can continue to use AES-128 as the encryption mechanism
2. Use HTTPS to provide the transport security.
3. Use token/cookie to authorize the user
(The cookie/token should be sent to the key server and the key server validates it before delivering the key)
Above 3 steps provide you the content protection, transport protection and to authorize users.
To answer your second question,
Authorized users with right tokens will be able to download the contents and keys to decrypt it. (There are plenty of tools to do it) you need a custom client to avoid that and html5 supported browsers cannot stop that.
We're playing around with WebRTC and trying to understand its benefits.
One reason Skype can serve hundreds of millions of people is because of its decentralized, peer-to-peer architecture, which keeps server costs down.
Does WebRTC allow people to build a video chat application similar to Skype in that the architecture can be decentralized (i.e., video streams are not routed from a broadcaster through a central server to listeners but rather routed directly from broadcaster to listener)?
Or, put another way, does WebRTC allow someone to essentially replicate the benefits of a P2P architecture similar to Skype's?
Or do you still need something similar to Skype's P2P architecture?
Yes, that's basically what WebRTC does. Calls using the getPeerConnection() API don't send voice/video data through a centralized server, but rather use firewall traversal protocols like ICE, STUN and TURN to allow a direct, peer-to-peer connection. However, the initial call setup still requires a server (most likely something running a WebSocket implementation, but it could be anything that you can figure out how to get JavaScript to talk to), so that the two clients can figure out that they're both online, signal that they want to connect, and then figure out how to do it (this is where the ICE/STUN/TURN bit comes in).
However, there's more to Skype's P2P architecture than just passing voice/video data back and forth. The majority of Skype's IP isn't in the codecs or protocols (much of which they licensed from Global IP Solutions, which Google purchased two years ago and then open-sourced, and which forms of the basis of Chrome's WebRTC implementation). Skype's real IP is all in the piece of WebRTC which still depends on a server: figuring out which people are online, and where they are, and how to get a hold of them, and doing that in a massively decentralized fashion. (See here for some rough details.) I think that you could probably use the DataStream portion of the getPeerConnection() API to do that sort of thing, if you were really, really smart - but it would be complicated, and would most likely stomp on a few Skype patents. Unless you want to be really, really huge, you'd probably just want to run your own centralized presence and location servers and handle all that stuff through standard WebSockets.
I should note that Skype's network architecture has changed since it was created; it no longer (from what I hear) uses random users as supernodes to relay data from client 1 to client 2; it didn't scale well and caused rampant variability in results (and annoyed people who had non-firewalled connections and bandwidth).
You definitely can build something SKype-like with WebRTC - and more. :-)
I need my Flash client to communicate with a server securely (through binary sockets). For this, I was thinking of embedding a pre-shared key inside the AS3 code and exchanging XORed data through a custom protocol.
I am told that SWF decompilers do a good job at making all embedded code clearly apparent and readable. Does this mean that I can't really hide my key?
If this method is impractical, what other options are there? I have tried as3crypto, only to find that it's full of shortcomings and lacks serious documentation.
You cannot hide your key at all - SWF is totally untrusted, can be easily decompiled. It's pretty difficult to deal with security with SWF's because they run on the client and are not trusted.
It might depend specifically on what you are trying to accomplish with secure communication. For instance, if you are trying to secure a high-score system that is pretty much impossible because the game runs on the client (the SWF) and they can manipulate it to spit out any score they want to the server. Here is a good read on this: What is the best way to stop people hacking the PHP-based highscore table of a Flash game
If you can use the SWF only as a front-end UI and all logic takes place on the back-end, then you can secure your application (using the above highscore example, if the game was not an AS3 game but actually ran on the server itself, it would be a lot easier to secure, because the backend is trusted and cannot be modified or viewed by a user), but if the logic takes place on the SWF then you are pretty much out of luck.
Over the years I've become an uber-nerd when it comes to flash game development. Now I'm thinking about looking into using my skills for helping other game-developers out there.
I want to develop an API in AS3 which will allow the developer to do (as a start) the following:
Display a dialogue which lets the user log into their "account" (hosted on my site).
Send a score/value to the website and attribute it to the logged in user.
Unlock an achievement (achievements will be set up by the developer in the web interface - which is where they will also get a key of some type to use with their API.
Display high scores, other players profiles in-game, etc (show basically any stats in-game).
All easy enough to develop straight off the bat. However; where it becomes frustrating is security. I'm not expecting an indestructible solution that I'm fully aware isn't possible, but what would be the most defensive way to approach this?
Here are the issues that I can think up on the spot:
The big one - people stealing the API key via man-in-the-middle attack.
Highscore injection, false achievement unlocks.
Decompiling the SWF and stealing the API key.
Using the API key to create a dummy flash application and send random data like highscores.
Altering the API itself so you don't need to be logged in, etc.
One thought I've had was converting my API to a component so there's no access to the code (unless you decompile). The problem here is it's just not friendly to the developers, though it would allow me to create my own graphics for the UI (rather than coding many, many sprites).
Private/public keys won't work unless there is very good protection against decompiling.
I'm beginning to wonder if this idea is a dead end.
Any advice on securing this (or parts of it) would be great.
Look at this thread first if you haven't done so already: What is the best way to stop people hacking the PHP-based highscore table of a Flash game
Against man-in-the-middle HTTPS seems the only option. It may have its vulnerabilities, but it's way better than any home-made solution. The problem that you'll need actual certificate from authorized center, because ActiveX-based Flash plugin will not trust self-signed certificate.
Should not be possible without decompilation
SecureSWF with reasonably high settings (code execution path obfuscation and encrypted strings) should beat most decompilers. Sure, SWF can be examined with hex editor, but this will require very determined hacker.
Should not be possible without decompilation
API should be on server and any API function would require user context (loaded by HTTPS)
Also add encryption to flash shared objects\cookies. I had successfully altered some savegames using simple hex editor, because they were just objects in AMF format. Encryption will depend on SWF decompilation, but since we are using SecureSWF... Or move savegames on server.
client side is never secure enough, so i'd suggest to take all the logic to the server, reducing client to just UI.
If it's impossible due to network timeouts - send scores/achievements only with the log of pairs "user_action - game_state" and verify it on the server.
What is a good framework to build a multiplayer game in Actionscript?
I want to create a multiplayer 2D shooter like Asteroids on the Blackberry Playbook; my main concern is latency - a shooter wouldn't be fun if the bullets are super-jerky and unexpectedly hit people.
I'm guessing that a UDP-based framework would be the best. Can anyone point me to the right direction?
There are many things you can use off the shelf but the basic setup is very simple but you have a few options.
The most common is server push, things like Flash Media Server, LiveCycle Data Services from Adobe or other tools like SmartFoxServer can do this. With this setup the server saves the connections to everyone that connects to the server and passes or "pushes" applications state to the people connected every time the data changes in the application.
Another option is called long pulling, this can be done with any web server really. How this works is the data stores the state of the application, when the application starts it calls the server, when it responds the client calls the server again.
There are a few other ways to do it but these are the most common. But this has nothing to do with protocol like HTTP, UDP, AMF, XMPP, or whatever else. The protocol is the format that the data is sent. With these out of the box servers they normally output a few of these but the fastest formats are binary like AMF but not always the best, there are advantages to each, because each gives you different features for keeping track of things.
If you are talking about have a game that takes over the world that has millions of users then you need to think about scaling and what happens when you need two or 100 servers and how do they talk to each other. But for now keep in mind that the more the server does the slower it will get, if you are sending small amounts of data it will be able to handle more users. Stick with making one efficient server and worry about that later if you get there.
You also need to thing about what server side programming language you want to mess with if any. Some services don't let you do anything, these normally cost money and don't do as much. Adobe likes Java but there are servers that output all of these protocols in most every language. My favorit lately has been Node.js a super fast way to run JavaScript on the server. Node.js has a built in HTTP server but it is just as easy to create a simple server that sends basic text through a Socket or XMLSocket. A server like this will easily handle many thousands of users. There are many games that use Socket.IO and if you want to see a simple example of what I'm talking about you can check out this.
Assuming you want to use Flash/Flex and not Java (Blackberry/Android) or native SDKs for Playbook -
There is a book as an inspiration: http://www.packtpub.com/flash-10-multiplayer-game-essentials/book it uses Pulse SDK at the server side. But you could use an own sockets-program on the server side. I use Perl as TCP-sockets server (sends gzipped XML around) in a small card game but this wouldn't work for your shooter.
Flash does not support UDP out of the box
But there is peer-to-peer networking protocol RTMFP in the upcoming Flash Media Server Enterprise 4 (price is out of reach for mere mortals)
So your best bet is to buy an Amazon-service for RTMFP then you can pay-per-use and stay scalable...
You can either do a constant post/get request with the server to get data for the game, but for a multiplayer shooter i'd surgest SmartFoxServer: http://www.smartfoxserver.com/
Out of the box, Adobe AIR supports UDP through datagram packets.
http://help.adobe.com/en_US/air/reference/html/flash/net/DatagramSocket.html
I couldn't find a particular networking API for flash, but perhaps you can build one. Libgren is open source and you can use that for reference.
You can also look into RTMFP though it's focus is on transmitting audio/video and some messages (through TCP I think).