[req]Tricking hulu?

[bugger]

I know Jakx scrips makes computer think we are just routers. Can it be used to fool hulu that one is from the US, so I can watch the video?

[Oddysey]

bugger;

Possibly. The picture gets complicated, though.

If HULU is using some form of IP screening, then the JakXPak filter stands a chance of getting you inside the theater. However, you have to know what address ranges they're screening for. Once you have that info, then you should be able to plug the numbers into the JakXPak, and kick back with a big bowl of popcorn.

Just be aware that many content providers who restrict access by geographical area are cognizant of this ability (whether provided by Proxo or some other spoofing method) - you may need to find an alternative method of crashing the party. But try this first, I think it has a good chance of working.

HTH


Oddysey

[bugger]

They screen for US base IP address and I live australia.

Jakxpak choose a random IP from sites i visited. Any method to do something like

Code:

if(hulu.com)
{ US base ip}
else
continue

[lnminente]

i worked on that the other day, but i needed to use an proxy from US

This filter helped at the beginning, but not with the ip...

Code:

[Patterns]
Name = "hulu: Remove geocheck {ln}081228"
Active = TRUE
URL = "\w.hulu.com/geoCheck"
Limit = 100
Match = "<geocheck> <status>not-valid</status> </geocheck>"
Replace = "<geocheck>"
          "  <status>valid</status>"
          "</geocheck>"

BTW, the link..... http://www.hulu.com/

---

Could someone from US post here the source code of this page to see the differences?

[Graycode]

(Jan. 09, 2009 01:26 PM)lnminente Wrote:  Could someone from US post here the source code of this page to see the differences?

You should be able to get the source by pasting your url at http://www.wannabrowser.com/
Its origin IP for the query is 64.111.122.20 (determined by having it get whatismyip.com).

[Kye-U]

When I load a video, I see:

Code:

+++GET 263+++
GET /sec.swf?cb=1231530853919 HTTP/1.0
Host: www.hulu.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.9.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
RESP 263 : Cache-Control replaced: max-age=3600
RESP 263 : Expires killed: Fri, 09 Jan 2009 20:54:15 GMT
RESP 263 : Time: 14:54:14::121

cb = current epoch time (I think)

I'm thinking sec.swf detects the IP address; I tried killing the connection with a header filter, but I still get "Sorry, this video is currently unavailable. We apologize for any inconvenience."

Maybe what we can do is get a hold of a US proxy, and compare/contrast the headers, one with our non-US IP address, and one behind the US proxy. It'd be nice if we wouldn't have to use a proxy at all (e.g. change a few values here and there), but I have a feeling that somewhere, we'd need to use a proxy.

[lnminente]

Graycode, clever tip to know the IP from wannabrowser, thanks!

Kye, my HTTP header is very similar, maybe it's a cookie thing. Thanks!

By now, i think the problem comes after http://cp39465.edgefcs.net/fcs/ident

[Graycode]

(Jan. 10, 2009 12:51 AM)lnminente Wrote:  By now, i think the problem comes after http://cp39465.edgefcs.net/fcs/ident

For me that link yields this:

Code:

cp39465.edgefcs.net/fcs/ident
====================================================
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 72
Server: FlashCom/3.0.2
Content-Type: application/xml

====================================================
<?xml version="1.0" encoding="utf-8" ?>
<fcs><ip>64.208.21.70</ip></fcs>
====================================================

Note that IP address. When trying to view a show, two nasty things happened.

1. Their Flash tried to bypass the browser's proxy settings. My firewall altered me several times that Firefox was trying to access 64.208.21.70, ports 1935 and 80. I don't let any browsing activity touch the internet except through my proxy. So be warned that you may need a firewall to stop them bypassing your Proxo, else your filters may be circumvented.

2. On several occassions my proxy flared up with a rarely seen error about invalid garbage being given for HTTP headers. Each time the garbage values were different, and only on POST to 64.208.21.70. My proxy verifies header integrity as self-defense, and I have very little tollerance for something that spews unpredictable crap for headers. Hopefully Proxo has some similar defenses or else Hulu may cause unpredictable abort.

I think I'm done with Hulu, maybe forever. Good luck with it.

[lnminente]

Graycode, very helpfull post again, i didn't realized the browser make connections bypassing the proxy settings to the ip indicated in http://cp39465.edgefcs.net/fcs/ident

This link also could be important http://t.hulu.com/config/v2/config?distro=Hulu

Code:

HTTP/1.1 200 OK
Date: Sat, 10 Jan 2009 15:44:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Connection: close

=======================================================

<?xml version="1.0" encoding="utf-8"?>
<beacons servertime="1231602294954">
  <beacon type="session" send="always" level="fatal" />
  <beacon type="component" send="never" level="fatal" />
  <beacon type="dataload" send="never" level="fatal">
    <event name="contentplaylist" send="onerror" level="fatal" />
    <event name="details" send="onerror" level="fatal" />
  </beacon>
  <beacon type="playback" send="always" level="fatal" />
  <beacon type="contentinteraction" send="always" level="fatal" />
  <beacon type="advertising" send="always" level="fatal">
    <event name="request" send="never" level="fatal" />
    <event name="response" send="never" level="fatal" />
  </beacon>
  <beacon type="revenue" send="always" level="error">
    <event name="request" send="never" level="fatal" />
    <event name="response" send="never" level="fatal" />
  </beacon>
  <beacon type="adinteraction" send="always" level="fatal" />
  <beacon type="abortedsession" send="always" level="fatal" />
</beacons>

[bugger]

any progress so far?

[sidki3003]

I doubt that you can "trick" Hulu, because the actual Flash content is streamed via RTMP (vs. HTTP), to the address that you've provided via HTTP:

Code:

<video src="rtmp://cp47346.edgefcs.net/ondemand/mp4:hulufms3..."/>

So you'd need a remote US proxy, probably Socks, because HTTP proxies speak, well, HTTP.
Then you'd need to convince your Flash plugin/AX-control to actually use that proxy.

It's a pitty because other major sites are using Hulu's services now as well.

[lnminente]

@bugger, I did some more investigations but got nothing, i wasn't able to redirect the flash connections across proxomitron

@sidki3k3, Many thanks Sidki, but i recognize this is really confusing for me. For me would be sufficient by now only knowing how to set a US proxy. I looked for proxies from US and tried them in proxomitron but i couldn't got them working...

[sidki3003]

http://kb.adobe.com/selfservice/viewCont...d=tn_16466 :

Quote:You are using a proxy server to connect to the Internet. Most proxy servers only negotiate HTTP traffic. For this reason, attempts to connect to the Macromedia Flash Communication Server using RTMP through a proxy server fail.

IOW, you might need a Socks proxy. However:

http://kb.adobe.com/selfservice/viewCont...&sliceId=1 :

Quote:Alternatively, a port number can be omitted from the URI:

nc.connect("rtmp:/mydomain.com/myAppName");

In the above case, the Macromedia Flash Player will first attempt to connect using port 1935. If a connection is not made, the player will then attempt to connect using port 80, and then port 443.

Blocking the first port of choice worked for me earlier, to force RealPlayer streams through Proxomitron.