[Think Tank #2 - SOLVED] Modifying Maps to enable Navigation outside USA
- Thread starter canadiancow
- Start date
The mangle table is used for altering packets, but requires implementation of the specifics by iptables modules. For example, the type of service, or TOS, module can change a packet's IPv4 TOS field. But someone had to go and write the TOS module for it to be able to do anything.
Having said that, we can possibly use iptables to redirect the packets to a transparent proxy running somewhere, perhaps on the phone. The proxy can then fudge the requests to Google so they look like regular map browser access rather than the "driveabout" Maps android application. If the requests are being filtered at the Google end, then we would need to pretend to be something else to avoid getting filtered.
The emulator can be configured to use a proxy very easily, which is what I'm doing.
I just don't have much experience with Squid (as it seems like the best option for what I need), and my development environment seems to be a little screwed up.
I'll make a new virtual machine later today, and try again.
Did you:
a) install Google Voice?
b) try to navigate within the US?
c) try creating a desktop shortcut to a "Directions" target and turn on navigation?
Modifying the app is a good idea.. but....
Silly question but......
Won`t this get google`s backs up??!!!
Has anyone got any idea of when navigation will roll out to the rest of us??
If I were working for google, i`d be wanting to rush the process along rather than have an app thats cost lots of money to develop, be tinkered with!
Come on google! Whats the time frame?!
Silly question but......
Won`t this get google`s backs up??!!!
Has anyone got any idea of when navigation will roll out to the rest of us??
If I were working for google, i`d be wanting to rush the process along rather than have an app thats cost lots of money to develop, be tinkered with!
Come on google! Whats the time frame?!
To avoid this thread become impossible to navigate, could we try to keep it on-topic?
Questions about getting Navigation working on your device should be posted in http://xdaforums.com/showthread.php?t=582656
philicibine, while I'm sure we would all prefer if Google would hurry up, there is nothing that I, personally, can do, to make Google work faster. However, I can try to get the existing application to work, and that is what I am attempting.
Questions about getting Navigation working on your device should be posted in http://xdaforums.com/showthread.php?t=582656
philicibine, while I'm sure we would all prefer if Google would hurry up, there is nothing that I, personally, can do, to make Google work faster. However, I can try to get the existing application to work, and that is what I am attempting.
a) Nope, kinda stopped paying attention to the other thread before the Google Voice stuff came up. I did have it installed a while ago for a very short period, but since it's not out in Australia yet it doesn't matter. (Unless you mean voice data, which i installed yesterday to play with TTS). What do i need to do this for?
b) Yep. No luck between two destinations.
c) Nope. I'll try now.
Edit: Just tried, no luck. Created a shortcut to San Francisco, it prompted me for a location so i said Detroit.. no Navigate.
Last edited:
We need a dump from a droid to compare the data, otherwise we're just guessing. Or possibly just a dump from a G1 that navigates in the US.
But to be honest, I looked at a wireshark dump myself and it seems to me that the application decides whether it can navigate or not. Either that or there's a flag embedded into the map data that's received. It's not trying to authorize to some other server or anything.
I have a dump from a successful navigation (this is where the emulator is very useful), and the data it received was significantly larger going from Las Vegas to San Francisco than it was going from Ottawa to San Francisco.
Except that the only difference between Navigation and regular "driving directions" seems to be what the app calls itself when it talks to the server, as I explained in my first post. So if we can get the app to call itself "GMM" instead of "DriveAbout", then it might work.
Didn't work. And I think it's not quite as simple as DriveAbout -> GMM. As these differences indicate:
Navigation:
POST goes to /glm/mmap/a
Host: header is www.google.com
Directions:
POST goes to /glm/mmap
Host: header is mobilemaps.clients.google.com
Also note that mostly the user agent is "null (sapphire DRC92); gzip" but on one occasion it changed to "GMM/3.0 (sapphire DRC92); gzip".
Finally, the strings "DriveAbout" and "GMM" are embedded in some sort of binary blob, and each string is prefixed by its length. So "\012DriveAbout" and "\003GMM". I even took adjusted the content length, to no avail.
Could be that I'm looking at completely different transactions. Now that my proxy rig up and running, I need to slow down and be a bit more methodical.
What about using the queue options from iptables (NFQUEUE)?
Then someone would just have to write the callback function (see http://linux.die.net/man/3/libipq) that modifies the packet (replaces the string) and does the admin stuff like recalculation md5 and ....
Maybe this howto is of use for any interested coder ;-)
Pushing this into userspace looks appealing.
I suspect it's a similar amount of work to writing any other extension/plug-in to iptables. There are plenty of guides and open-source examples to use, but much of the work would be in getting a toolchain to build kernel modules and libraries for the Android platform. Need to check that stock Android has the libipq library, otherwise we'd need to build and install it. This is all probably relatively easy, but my current lack of dev knowledge is making it seem harder. But don't let that stop us.
So the plan would be to have a script run when networking comes up, applies an iptables rule that matches outgoing port 80 packets, and pushes them to a userspace queue. We also write an app, need not run as root, which might make installation easier. The app gets packets from the queue, looks for packets going to google domains (in host header), looks for packets containing DriveAbout in the body, changes this to GMM (and likely some other fix-ups that we find along the way), re-calculates the checksum, and sends the packet on its way.
Have we confirmed that changing "DriveAbout" to "GMM" will work? I didn't want to start modifying a real device until it was working in an emulator. The emulator lets you bypass everything you mentioned about iptables, because you can start it with the -http-proxy option.
Hi there...
I m interested a lot in these pages.
Since i reversed the market application doing marketEnabler (The one which enable outside US people to buy apps from the market ) i could probably help..
As far i can remember the encoded data sent by marketEnabler was encoded with some kind of base64 encoding ..
It was a little modified but you can make a test with the simple base64 decoder routine and see if something changes..
Furthermore i think google did the client-side check because they knew someone will started working on hacking this .. ( Doing for marketEnabler was so simple )...
Fur the reasons above i do think there are no server side checks.
Hope this helps
I m interested a lot in these pages.
Since i reversed the market application doing marketEnabler (The one which enable outside US people to buy apps from the market ) i could probably help..
As far i can remember the encoded data sent by marketEnabler was encoded with some kind of base64 encoding ..
It was a little modified but you can make a test with the simple base64 decoder routine and see if something changes..
Furthermore i think google did the client-side check because they knew someone will started working on hacking this .. ( Doing for marketEnabler was so simple )...
Fur the reasons above i do think there are no server side checks.
Hope this helps
Hi there...
I m interested a lot in these pages.
Since i reversed the market application doing marketEnabler (The one which enable outside US people to buy apps from the market ) i could probably help..
As far i can remember the encoded data sent by marketEnabler was encoded with some kind of base64 encoding ..
It was a little modified but you can make a test with the simple base64 decoder routine and see if something changes..
Furthermore i think google did the client-side check because they knew someone will started working on hacking this .. ( Doing for marketEnabler was so simple )...
Fur the reasons above i do think there are no server side checks.
Hope this helps
A client-side check is almost always easier to circumvent than a server-side check. If it's client-side, then we're looking in the wrong place, and this will probably be a lot easier.
could you attach a sample packet?
I don't have the time to do the emulator stuff but I'm maybe able to help with decoding a bit...
@Vekexasia: nice that you joined this thread ;-)
I don't have the time to do the emulator stuff but I'm maybe able to help with decoding a bit...
@Vekexasia: nice that you joined this thread ;-)
