Simulating Farmville on Facebook with the BreakingPoint Storm CTM
by Steve McGregoryLast time I talked about how we’ve built support for Facebook protocols into the BreakingPoint Storm CTM. In this post I’ll demonstrate how to use the machine to simulate Web applications running on Facebook, using Farmville as an example. Farmville is a very popular social networking game that has more than 26 million daily users.
The first step is to get a test Facebook account. If you don’t play Farmville on your personal account, then create a secondary account, and Facebook would probably like you to mark this secondary account as a “Test Account.”
To get started creating a Farmville Super Flow, we need to set up the Facebook API flow. This flow will configure Facebook application settings for Farmville. The screen for this is below, and the data for the fields is retrieved through Facebook.
Farmville will need to request authorization to access some of your Facebook data. As I write this, they are requesting access to your “Birthday,” “Location,” and “Email.” We’ve supplied this in the “Farmville” Super Flow → Facebook API → Authorize action.
Now we need to capture some of the network traffic for a real Farmville session. Use your favorite packet capture utility, something like Wireshark. (If you use Firefox, another cool HTTP packet analyzer is HTTPFox.) Enable the packet capture, then from within Facebook search for “Farmville,” then click the “Go to Application”. After you’ve allowed Farmville authorization to these data points, the game will load. In this example Farmville is running as a Facebook canvas application. The Farmville application itself is a Flash program; when you inspect your PCAP, you’ll see that it loads a number of SWF files (along with support files); from that point, communication of your game actions is done through the Farmville servers.
After a brief review of the PCAP, I determine that Farmville is a Flash application and identify a few GET/POST requests that I’ll implement using the BreakingPoint Storm CTM built-in HTTP protocol handler. I download a couple of the important SWF files, and will upload these along with other support files. The SWF files will be transmitted during our Application Simulator session.
Going back to the BreakingPoint Application Manager, I’ll add a new Flow using the HTTP protocol. This flow is configured to connect to the Farmville host in out Hosts configuration. The development team has provided a very flexible and powerful HTTP protocol support. I cannot think of any HTTP application that could not be implemented using this Flow protocol. (If you find something, let me know and we’ll fix it!) As you can see in the screen shot below, you can configure the HTTP Flow in many different ways.
After the HTTP Flow is added to the Super Flow, we start adding the actions. From the PCAP the first action I’m going to add is an HTTP GET of the SWF file /embeds/v50372/FV_Preloader.swf.
Following the GET I’ll add a RESPONSE 200 result from server.
Then I upload the SWF file that I downloaded from the Farmville server, telling the response to include that file as data.
Repeat that action for each of the GET requests you’d like to perform in the Application Simulator session. If you would like to perform a list of GET requests, you can do so by using the GETURIs action. Using GETURIs you will upload a file containing the list of URLs to perform GETs within that session. This bulks up the session requests.
Once the Farmville application is loaded, the Flash code will process user actions through HTTP POST requests to /flashservices/gateway.php.
Looking at the HTTP Header for the POST, you see cookie information for a PHPSESSID and other variables. It would be preferred that this data be variable based on the Flow. An Application Simulator session will create many Flows. A Flow can be associated with a user session and, since many users are on the network, you want many Flows. Each user session will have a different PHPSESSID. To accomplish this we are going to create a file that the POST action will use for the Header information. Here’s our post file with Header information:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.04 (lucid) Firefox/3.6.12 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: PHPSESSID=##alphanum(seed_flow,26)##; 80c6ec6628efd9a465dd223190a65bbc=cb255bc5988b7a9abfbc2fd546bda23b; 80c6ec6628efd9a465dd223190a65bbc_ss=EC0z92U018MlmFh3BJ_ylg__; 80c6ec6628efd9a465dd223190a65bbc_expires=1288378800; 80c6ec6628efd9a465dd223190a65bbc_user=100001572911816; 80c6ec6628efd9a465dd223190a65bbc_session_key=2.nKgh_M2BIad7TIFt15J3cw__.3600.1288378800-100001572911816; 80c6ec6628efd9a465dd223190a65bbc_expires=1288382400; 80c6ec6628efd9a465dd223190a65bbc_session_key=2.TZ9cRwpyeFTNhCt1N5KRzQ__.3600.1288382400-100001572911816; 80c6ec6628efd9a465dd223190a65bbc_ss=i4b7m44JUGgd4fSTc9Uzig__; 80c6ec6628efd9a465dd223190a65bbc_user=100001572911816; 80c6ec6628efd9a465dd223190a65bbc=36803562866ed5abf8f28b9d3de4c281; base_domain_80c6ec6628efd9a465dd223190a65bbc=farmville.com; fbsetting_80c6ec6628efd9a465dd223190a65bbc=%7B%22connectState%22%3A1%2C%22oneLineStorySetting%22%3A3%2C%22shortStorySetting%22%3A3%2C%22inFacebook%22%3Atrue%7D Referer: http://static.farmville.com/embeds/v50372/FarmGame.release-10-10-29.50372.swf Content-Type: application/x-amf
Notice the (PHPSESSID=##alphanum(seed_flow,26)##) that is in bold in the file text. This is an example of how you can tell the system to create a random string for the Flow. In this example it will insert an alphanumeric string 26 characters long. (See the documentation for further random string support functions.)
I also created a POST data file and used some randomly generated strings for the variables to mimic different POST calls. Below you can see part of the POST action configuration and the specification of these files to use for the action.
After adding all of the GET and POST actions plus their equal server responses, I now have a Super Flow that the Application Simulator component can use to simulate millions of Farmville users on a network. Apply these new Super Flows to your network Application Profiles along with your ATI security checks, and now you’re running real-world security analysis.
In conclusion, the application protocol stack does not end at HTTP. As we are seeing, HTTP is now getting layers of sub-protocols. With the BreakingPoint Storm CTM™ you can model these new protocols and run at performance numbers unlike any other device on the market today. Our trials of these new Super Flows shows that one BreakingPoint Storm CTM™ is capable of generating traffic mixes of tens of millions of Facebook and Farmville users. By simply extending the built-in HTTP protocol support, you can get tens of millions of user flows on the HTTP application of your choice.
We’d love to hear from you about this. How will you use these Super Flows in your network environment?
