search

KLSnRPA / omaha

Automatically exported from code.google.com/p/omaha
Apache License 2.0
0 stars 0 forks source link

Can't resolved detecting download URL of 64-bit builds by GET #64

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Last year I discovered direct download URLs of Chrome builds. Of course it's 
available "codebase" string inside of XML files.

STABLE version:
http://clients2.google.com/service/update2/crx?x=id%3D{8A69D345-D564-463C-AFF1-A
69D9E530F96}%26uc

BETA version:
http://clients2.google.com/service/update2/crx?x=id%3D{8A69D345-D564-463C-AFF1-A
69D9E530F96}%26uc&ap=1.1-beta

DEV version:
http://clients2.google.com/service/update2/crx?x=id%3D{8A69D345-D564-463C-AFF1-A
69D9E530F96}%26uc&ap=2.0-dev

CANARY version:
http://clients2.google.com/service/update2/crx?x=id%3D{4ea16ac7-fd5a-47c3-875b-d
bf4a2008c20}%26uc

Google released 64-bit version of Chrome Dev & Canary. I wanted can detecing 
64-bit URLs XML same URL/GET method. So, I changed suffix of URLs;

DEV version:
http://clients2.google.com/service/update2/crx?x=id%3D{8A69D345-D564-463C-AFF1-A
69D9E530F96}%26uc&ap=ap=x64-dev

CANARY version:
http://clients2.google.com/service/update2/crx?x=id%3D{4ea16ac7-fd5a-47c3-875b-d
bf4a2008c20}%26uc&ap=x64-canary

Unfortunately, only detect 32-bit links, not 64bit. I don't understand why. 

is that not true strings for x64?
ap=x64-dev for DEV
ap=x64-canary for Canary

Which am I use &ap=.... in suffix?

Thank you in advance for your interest.

Original issue reported on code.google.com by pureoce...@gmail.com on 25 Jun 2014 at 6:34

GoogleCodeExporter commented 8 years ago 
The query parameters and the actual resource referred by the "codebase" element 
in the update response are implementation details and they are likely to change 
at any time. In particular, I don't know the answer to your question. At any 
rate, expect things to break if your system depends on any of the artifacts 
above.

Original comment by so...@google.com on 18 Aug 2014 at 6:38

GoogleCodeExporter commented 8 years ago 
funny how your issue# matches your 'problem'.
what on earth made you think 1.1 or 2.0 is in any way related to a 32-bit 
platform? especially if the stable version doesn't show such suffix at all 
and--as you mentioned by yourself--the links are 'older' than the advent of a 
dedicated 64-bit version.
so, as a brief conclusion: no, your estimation definitely won't lead you to a 
64-bit D/L-link but unfortunately I'm also not knowing which link you should 
use instead.
as the updater isn't part of the chromium project it also isn't open source, 
hence you can't just skim through the code in order to retrieve all relevant 
urls. but you could try and install some 64-bit version and then use wireshark 
in order to sniff the url it is referring to.
oh, and let us know if you have success (including the links you got, of 
course...)
good luck!

ps: I kinda disagree with post #1 as I would expect these links lasting pretty 
long.
pps: get yourself a new translation program; your current one suxxx.
ppps: I expect the 'ap=' appendix to be the very same for the 64-bit version.
pppps: oh, utf-8 formating leads to an error 400 (bad request); ok, good to 
know.

Original comment by H.E.R.O....@gmail.com on 8 Oct 2014 at 10:12

GoogleCodeExporter commented 8 years ago 
ups, I just found out, there obviously is no separate 64-bit binary. it is all 
combined into one package and would behave accordingly not upon installation 
fwik but upon run.

ps: sorry about the possibly rude language skill remark; I wouldn't dare to say 
if English weren't only my 2nd language either.

Original comment by H.E.R.O....@gmail.com on 8 Oct 2014 at 2:32