izSpK
BANNED
- Sep 5, 2010
- 1,511
- 1,688
Last thread was removed due to a few things, but I am going to post this, and instantly close it so butthurt viewsellers won't get mad and cause drama/stress for mods and admins. Please leave a THANKS to keep these coming, as I have a few parts I will post weekly. Also this is for educational purposes only, hence no software is given out here.
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime"
I just want to clear up, the method explained is way more valuable (to some) than the actual bot. Although I will show snippets how to do the different things, this thread is more based on the method itself, how it is done, and so on.
There is no functional bot in this thread, but I'd appreciate if someone took the time to release one (I have too much work to do, and I really don't have the time to code anything else at the moment)
Part 1 - The ‘mobile method'
So I've been looking around, and there is constantly new view providers popping up, and most of them are doing mobile views. But wait SpK, the views show up as Facebook.com and Twitter.com referrals, how come? Well, I will be explaining how these guys do that.
The views are just as worthless. Let's start, shall we?
This has to be the easiest method out there, and I am kind of surprised not too many know about this. Anyways, this is how to do it:
First of all, we need to turn into an iPhone or Android. How do we do this? We can use Chrome, and an extension called "Chrome UA Spoofer". After we've done this, we grab Fiddler2 (http://www.fiddler2.com/fiddler2/). Turn on Fiddler2, and navigate to YouTube (with iPhone 4 user-agent turned on), then watch any video on YouTube. Let's analyze the requests inside Fiddler2 now. This is what I got after watching the entire video:
So as we can see, while watching the video, it sends numerous "s.youtube.com" requests. For those who don't know, this is YouTube's Video Stats Server (according the response header "Server: Video Stats Server"). This is the server that counts the views, and everything else that has to do with video statistics (basically everything in your analytics).
Now let's take a look at the parameters sent over to the server from our browser. I will be explaining in detail what each one of these tells the server.
on3g=0
This basically means that the phone is not watching this via 3G.
app=youtube_mobile
This is the main parameter in this method. By telling YouTube's statistic servers that you are a mobile phone, you bypass most security such as X views per IP per 24 hours, etc. It basically turns the filters off.
preq=%2Fwatch%3Fajax%3D1%26feature%3Dm-trends%26layout%3Dmobile%26tsp%3D1%26v%3Dyk_7ol-bSU8
This is basically the end of the URL you've navigated to.
reloadCount=0
Every single request I've sent, this has been 0, and I don't think it will change in the near future. It's basically how many times you've reloaded the video (I think).
rdm=m4vdvn22r
The last 3 characters of this changes randomly (with no pattern that makes sense), so I just do the same as the JavaScript files, and append 3 random characters after "m4vdvn". The views count, so it should be right.
html5=1
Tells YouTube that we are using the html5 mobile player, and not something else (though there are not too many available alternatives, I have no clue why this is one of the parameters)
ns=yt
"ns" means namespace, and it is always "yt" (YouTube). Never analyzed a video with a different value.
ps=blazer
"ps" means player-style, and the mobile-player is codenamed "blazer".
el=detailpage
"el" means "Event Label", and "detailpage" means what we all refer to as "watch page". (the default page we watch the video on)
hl=en
"hl" is the interface language, and "en" is English.
cr=US
"cr" is country region, and "US" is the United States. Changing this sometimes changes the location of the video (geo-targeting), but it is not always working. (they base it of IP most times, but when they turn off the initial filters, changing country region usually works)
docid=yk_7ol-bSU8
"docid" basically means the video ID. The thing usually after the "/watch?v=".
plid=h306l6771pavjfv1u
"plid" means playback ID token value, and can be scraped from the HTML.
fmt=18
Basically means which format the video is in. If you've ever coded a video downloader before, you would know what 18 is. Although, you can just watch the video 1 time with Chrome (+ UA spoofer) and find out which format it is, then use that to send the requests. It will never change (for that specific video)
fs=0
Is the video played back in full screen? 1 = true, 0 = false.
screenw=320
Screen width.
screenh=533
Screen height.
w=1
Width (Chrome + UA spoofer bug, it was 1px on my end)
h=2
Height (Chrome + UA spoofer bug, it was 2px on my end)
vw=0
Video width (Chrome + UA spoofer bug, it was 0px on my end)
vh=0
Video height (Chrome + UA spoofer bug, it was 0px on my end)
playerw=316
Player width
playerh=2
Player height
rt=30.252
Basically, here is my calculation of this parameter:
Code:
rt = ((getTimer() - playbackStartTime) / 1000).toFixed(3);
It means, current unix time, subtracted by the time the player started playing (unix time, you have to store this), divided by a thousand, and round to 3 decimals.
sw=1
Stands for sampling weight although I have no clue what that means.
len=218.635
Length of the video in seconds. This has to be accurate, and you can get it by watching the video legitimately 1 time, and find the values in Fiddler2, or any other HTTP analyzer out there.
st=17.643
This means "start seconds", and is the value of which time in the video it sent the LAST request. First request, both et and st will be the same.
et=27.65
This means "end seconds", and is the value of which time in the video it sent the CURRENT request. First request, both et and st will be the same.
How this is used to send "Facebook and Twitter" views
So, the people who know about this method were kind of smart, and though: "Hey if it shows up as mobile, and can easily be emulated, can't we make it look like it comes from elsewhere?" And they figured out how to do this.
I know a few people that own sites that sell views, and gigs on Fiverr that currently do this, and it is basically just a ripoff, and the price gives away that. There is no way people can sell real views at such prices.
Now let's look at how it is done. When watching a video legitimately with a real PC, and actually being referred through Facebook, we get a parameter called "sdetail", and "referrer". I figured out that "sdetail" is not important, so let's focus on "referrer". By adding a little parameter to the mobile request (with "app=youtube_mobile" and all that jazz), called "referrer=URL", we can make the views come from anywhere. So basically appending "referrer= http%3A%2F%2Ffacebook.com%2F" (url-encoded) to the parameter list, it will come from Facebook. Wasn't that easy? Well, it sure does look good and all that, but from all the tests I've done (and just to let you know, that's a TON), it never has any positive SEO-impact to the videos. I've heard people say that it does, but that was BEFORE, when the RTSP glitch still worked (oh, by the way, it works again).
Mobile views do not really mean much, but that changed today (03.06.2012). By adding "et" (end time) and "st" (start time) mobile views now shows audience retention to the video statistics server, meaning it now adds SEO-juice. You heard it here first They used to not send rt, et and st, but they added it last night, meaning they want to use mobile views in their SEO algorithm (and this is the reason some sites such as SquidRootBeer do not offer mobile views since last night)
Part 2 will be released next week, and I will talk about another common method these fake "view sellers" use. This one will be a little trickier. Until then, peace out.
Credits to "the known" for countless of hours of testing with me. <3
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime"
I just want to clear up, the method explained is way more valuable (to some) than the actual bot. Although I will show snippets how to do the different things, this thread is more based on the method itself, how it is done, and so on.
There is no functional bot in this thread, but I'd appreciate if someone took the time to release one (I have too much work to do, and I really don't have the time to code anything else at the moment)
Part 1 - The ‘mobile method'
So I've been looking around, and there is constantly new view providers popping up, and most of them are doing mobile views. But wait SpK, the views show up as Facebook.com and Twitter.com referrals, how come? Well, I will be explaining how these guys do that.
The views are just as worthless. Let's start, shall we?This has to be the easiest method out there, and I am kind of surprised not too many know about this. Anyways, this is how to do it:
First of all, we need to turn into an iPhone or Android. How do we do this? We can use Chrome, and an extension called "Chrome UA Spoofer". After we've done this, we grab Fiddler2 (http://www.fiddler2.com/fiddler2/). Turn on Fiddler2, and navigate to YouTube (with iPhone 4 user-agent turned on), then watch any video on YouTube. Let's analyze the requests inside Fiddler2 now. This is what I got after watching the entire video:
So as we can see, while watching the video, it sends numerous "s.youtube.com" requests. For those who don't know, this is YouTube's Video Stats Server (according the response header "Server: Video Stats Server"). This is the server that counts the views, and everything else that has to do with video statistics (basically everything in your analytics).
Now let's take a look at the parameters sent over to the server from our browser. I will be explaining in detail what each one of these tells the server.
on3g=0
This basically means that the phone is not watching this via 3G.
app=youtube_mobile
This is the main parameter in this method. By telling YouTube's statistic servers that you are a mobile phone, you bypass most security such as X views per IP per 24 hours, etc. It basically turns the filters off.
preq=%2Fwatch%3Fajax%3D1%26feature%3Dm-trends%26layout%3Dmobile%26tsp%3D1%26v%3Dyk_7ol-bSU8
This is basically the end of the URL you've navigated to.
reloadCount=0
Every single request I've sent, this has been 0, and I don't think it will change in the near future. It's basically how many times you've reloaded the video (I think).
rdm=m4vdvn22r
The last 3 characters of this changes randomly (with no pattern that makes sense), so I just do the same as the JavaScript files, and append 3 random characters after "m4vdvn". The views count, so it should be right.
html5=1
Tells YouTube that we are using the html5 mobile player, and not something else (though there are not too many available alternatives, I have no clue why this is one of the parameters)
ns=yt
"ns" means namespace, and it is always "yt" (YouTube). Never analyzed a video with a different value.
ps=blazer
"ps" means player-style, and the mobile-player is codenamed "blazer".
el=detailpage
"el" means "Event Label", and "detailpage" means what we all refer to as "watch page". (the default page we watch the video on)
hl=en
"hl" is the interface language, and "en" is English.
cr=US
"cr" is country region, and "US" is the United States. Changing this sometimes changes the location of the video (geo-targeting), but it is not always working. (they base it of IP most times, but when they turn off the initial filters, changing country region usually works)
docid=yk_7ol-bSU8
"docid" basically means the video ID. The thing usually after the "/watch?v=".
plid=h306l6771pavjfv1u
"plid" means playback ID token value, and can be scraped from the HTML.
fmt=18
Basically means which format the video is in. If you've ever coded a video downloader before, you would know what 18 is. Although, you can just watch the video 1 time with Chrome (+ UA spoofer) and find out which format it is, then use that to send the requests. It will never change (for that specific video)
fs=0
Is the video played back in full screen? 1 = true, 0 = false.
screenw=320
Screen width.
screenh=533
Screen height.
w=1
Width (Chrome + UA spoofer bug, it was 1px on my end)
h=2
Height (Chrome + UA spoofer bug, it was 2px on my end)
vw=0
Video width (Chrome + UA spoofer bug, it was 0px on my end)
vh=0
Video height (Chrome + UA spoofer bug, it was 0px on my end)
playerw=316
Player width
playerh=2
Player height
rt=30.252
Basically, here is my calculation of this parameter:
Code:
rt = ((getTimer() - playbackStartTime) / 1000).toFixed(3);
It means, current unix time, subtracted by the time the player started playing (unix time, you have to store this), divided by a thousand, and round to 3 decimals.
sw=1
Stands for sampling weight although I have no clue what that means.
len=218.635
Length of the video in seconds. This has to be accurate, and you can get it by watching the video legitimately 1 time, and find the values in Fiddler2, or any other HTTP analyzer out there.
st=17.643
This means "start seconds", and is the value of which time in the video it sent the LAST request. First request, both et and st will be the same.
et=27.65
This means "end seconds", and is the value of which time in the video it sent the CURRENT request. First request, both et and st will be the same.
How this is used to send "Facebook and Twitter" views
So, the people who know about this method were kind of smart, and though: "Hey if it shows up as mobile, and can easily be emulated, can't we make it look like it comes from elsewhere?" And they figured out how to do this.
I know a few people that own sites that sell views, and gigs on Fiverr that currently do this, and it is basically just a ripoff, and the price gives away that. There is no way people can sell real views at such prices.
Now let's look at how it is done. When watching a video legitimately with a real PC, and actually being referred through Facebook, we get a parameter called "sdetail", and "referrer". I figured out that "sdetail" is not important, so let's focus on "referrer". By adding a little parameter to the mobile request (with "app=youtube_mobile" and all that jazz), called "referrer=URL", we can make the views come from anywhere. So basically appending "referrer= http%3A%2F%2Ffacebook.com%2F" (url-encoded) to the parameter list, it will come from Facebook. Wasn't that easy? Well, it sure does look good and all that, but from all the tests I've done (and just to let you know, that's a TON), it never has any positive SEO-impact to the videos. I've heard people say that it does, but that was BEFORE, when the RTSP glitch still worked (oh, by the way, it works again).
Mobile views do not really mean much, but that changed today (03.06.2012). By adding "et" (end time) and "st" (start time) mobile views now shows audience retention to the video statistics server, meaning it now adds SEO-juice. You heard it here first
They used to not send rt, et and st, but they added it last night, meaning they want to use mobile views in their SEO algorithm (and this is the reason some sites such as SquidRootBeer do not offer mobile views since last night)Part 2 will be released next week, and I will talk about another common method these fake "view sellers" use. This one will be a little trickier. Until then, peace out.
Credits to "the known" for countless of hours of testing with me. <3
