Reverse Understanding – gaednsproxy.appspot.com Service

dns
appspot is a sandbox/playground (whatevvvvveeeerrrr….) for apps…served by Google Frontend servers

breaking the logic without any whitepapers was quite easy…

I was proxy’ing my phone’s addresses, through my PC’s FIDDLER, this is a monthly routine,
since I need to keep up with all the junk push through publishers, through their new updated applications,
after I’m maintaining a list of all new PING, TRACKING, STATISTICS, ADVERTISEMENTS and plain old UNNEEDED JUNK,
I’m adding it to my sub-website hosts.eladkarako.com.

this time I’ve noticed something cool: using the host-name: gaednsproxy.appspot.com with a simple mimetype of text/html and short GET request: http://gaednsproxy.appspot.com/?d=WTJ4cFpXNTBjek11WjI5dloyeGxMbU52YlE9PQ%3D%3D

request was made by some open source application named DroidFu:

GET http://gaednsproxy.appspot.com/?d=WTJ4cFpXNTBjek11WjI5dloyeGxMbU52YlE9PQ%3D%3D HTTP/1.1
Host: gaednsproxy.appspot.com
User-Agent: Android/DroidFu
Connection: close
Connection: close

response was just an ip..


HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Dec 2014 07:56:31 GMT
Server: Google Frontend
Cache-Control: private
Alternate-Protocol: 80:quic,p=0.02
Connection: close

74.125.28.101

looks like an escaped-base64 argument, I’ve thought..
using my good old base64 enc/dec here

it was double enc/ in base64

so…

WTJ4cFpXNTBjek11WjI5dloyeGxMbU52YlE9PQ%3D%3D
(unescaped)->
WTJ4cFpXNTBjek11WjI5dloyeGxMbU52YlE9PQ==
(first base64 decode)->
Y2xpZW50czMuZ29vZ2xlLmNvbQ==
(second base64 decode)->
clients3.google.com

ip

so this one was just a simple reverse hostname (clients3.google.com) to IP (74.125.28.101)…
double base64 looks kind’a overkill, fishy?? don’know..

from my experience it just may be a plain Anti-Fraud (Anti Man-In-The-Middle, Proxy/DNS Poisoning, etc…),
this way the IP is resolved through an external-server (a.k.a “safe place”), other then a risked machine (self Android device),

simple but effective….

Leave a Reply