Solution for Viewing Blocked Media Content on Flash 10.1 Devices?

Recently, an increasing number of media companies have been blocking access to Flash 10.1 content on non-PC devices (i.e. Android Phones, Google TV, PS3, etc.).  The reasoning for this makes no sense as I can plug my laptop into my TV and watch sites like Hulu, Fox.com, and NBC.com content without any problems.  However, doing so on a game console, Google TV device, or even an Android Phone is somehow different in their view.  It shouldn’t be a DRM issue either, as that should be handled by the Flash player itself.

Oh well.  In the past, this could be worked around by simply altering the user-agent string on the browser.  In this case, the browser would basically lie to the server and trick it into thinking that it’s running on a PC web browser.  As a result, the content would play just fine.

However, that no longer works.  Instead of simply relying on the user agent string of the browser, they are now also looking at the version of Flash Player running on the device.  A string of the version of Flash you are running is sent to the server to check if you are using a “supported device.”  You can find out what your Flash version string is by visiting this page: http://kb2.adobe.com/cps/155/tn_15507.html.  Visiting that page should show you something similar to this:

Screenshot of the Flash Player version string

To verify that this string is actually being sent to the server, I opened up Wireshark and sniffed some traffic on Hulu.  While watching an episode of Hells Kitchen on Hulu, I sniffed for HTTP GET requests.  Below is a screenshot of the TCP Stream for the GET request:

TCP Stream of the GET Request

As you can see from the screenshot above, there are a lot of variables appended to the GET request.  The most interesting one is the: flashPlayer=WIN%2010%2C1%2C103%2C19. This tells the server which version of Flash Player the system is running. If you remove the delimiting characters from the GET request, you would see that the version string matches that of the string in the first screenshot above. If you were running Android, the version string would contain AND instead of WIN.

That is not the only GET request of interest.  Indeed, there are others which contain appended variables declaring the OS, and the browser being used.  All of this information together can identify the device accessing the service.  However, remember that because all of this code is coming from the client, it can be altered.

So, in theory, if we were to replace the Flash Player version (as well as any other string sent to the server that could reveal the identity of the device accessing the service) with known values that work (such as one from an ordinary PC), that device should be able to access the service, since the server thinks the device is just a regular, “supported” PC.

Unfortunately, modification of the packet on-the-fly is the problem.  I cannot find any suitable software that is capable of making these changes on-the-fly to the HTTP packets.  A proxy application would be best suitable for this purpose, as it can change the user-agent-string and potentially other variables within the packet before being sent out to the server.  Unfortunately, I cannot locate any software that would easily give me the granular control needed to make this work.

After looking into Squid, and Privoxy, the best application that I have tested so far is TcpCatcher (http://www.tcpcatcher.org/).  This is a great app that basically combines Wireshark with a proxy server for HTTP connections.  It can even perform find-and-replace functionality within the packet.  Unfortunately, as powerful as the application is, it does not have the ability to find-and-replace more than one variable at one time. For example, to make this work, I would need to change the user-agent string, as well as find-and-replace any instances of flashplayer=, flash=, and even os= with known values that work.  However, this application can only allow one or the other to be changed.  If I change the user-agent string, I cannot perform a find-and-replace on the packet.  Thus, it will not work to fix the problem, as we need to completely mask the identity of the accessing device and trick the server into thinking that it’s just an ordinary PC.

If anyone is able to locate software that can make this work, please post it in the comments.

Share and Enjoy:
  • LinkedIn
  • Facebook
  • Twitter
  • Google Bookmarks
  • Reddit
  • Alex

    I ran across this, someone used this to unblock the PS3

    http://www.ypass.net/blog/2009/09/got-a-ps3-want-hulu-back-and-youre-a-windows-user-also-easy-enough%E2%80%A6/

    http://www.proxomitron.info/45/help/Contents.html

    Don’t know if it works but worth a shot. Looks reasonable.

    • http://slashsarc.com /sarc

      Thanks for that. I’ll have to check out proxomitron. The main problem with most of the proxys I’ve come across is that they mostly only filter out the user-agent string. Unfortunately, that is just not enough anymore since they are now checking the version of Flash that is running.

  • http://www.joursouvres.fr chris

    You can actually chain several packets modification using the TcpCatcher java api.
    In your case you would write a simple java class that may look like this :


    if (tcpcatcherPacket.fromClient) {

    //First change User Agent Header
    tcpcatcherPacket.removeHttpHeader("User-Agent");
    tcpcatcherPacket.insertHttpHeader("User-Agent",
    "whatever user agent");

    //then perform several changes on packet payload

    String httpContent=tcpcatcherPacket.getHttpContent();

    if (httpContent!=null)
    {
    String newhttpcontent=httpContent.replaceAll("flashplayer=..","...");

    newhttpcontent=newhttpcontent.replaceAll("flash=..","...");

    newhttpcontent=newhttpcontent.replaceAll("os=..","...");

    //change http content
    tcpcatcherPacket.setHttpContent(newhttpcontent);

    }

    }

    then plug it to TcpCatcher. More explanations here

    • http://slashsarc.com /sarc

      Wow that’s really cool! That may keep me busy for a while.

Copyright © /sarc All Rights Reserved · Using modified version of Green Hope Theme by Sivan & schiy · Proudly powered by WordPress