Comment Re:google should have turned a blind eye. (Score 1) 323
> I'm on the Google Earth team and yes, this is exactly what happened.
> The license we have to the imagery forbids us from allowing access
> from unofficial clients. The data providers take this very seriously
> indeed and noticed very quickly that such an application was out in
> the wild.
I must admit, that as soon as I read about Gaia you couldn't have counted to 1 until I fed wget with the URL. But instead of thinking about a Client replacement I was thinking more about a caching proxy, i.e. using the knowledge gatherd from reading the source to build a server, that the GE Client would mistake for the official one. Then using that tool, someone could download a given area where he might not have Internet access, working there using GE to makes nots about certain landmarks (e.g. if you're a geocacher).
Honestly I think Google - or Keyhole, the original developers of the software - is to blame for the whole mess. There is practically no protection in the protocol albeit a weak encryption scheme and a session cockie and probably access resticted to HTTP clients with a special client ID. Reverse Engineering? Is it reverse engineering if your aunty makes the best cookies in the world, won't give you the reciepe, but you may watch her as she bakes them, speaking out load the contents of the reciepe with the only protection being, that she calls flour "wheat millings" water "dihydroxylacid" and butter "processed milk residue".
What could have Google done to protect the data? First step: Encrypt the whole communication. Google Earth comes with OpenSSL but seemingly it is not used. Don't want the connection been made by an arbitrary client, then use HTTPS with a shared secrect. To make sure, nobody tinkers with the SSL library compile that statically into the program (LD_PRELOAD anybody?). In fact: Link everything statically. Now were at the point where really reverse engineering must be done, at least we have to disassemble the program (EULA forbids that, but lets just assume, an attacker ignores that). You can eliminate a lot of uncertanties by looking which third party libraries GE uses (is those are statically linkes have a look into licence.txt). Compile those libraries with the same compiler like the GE binary (look into the ELF header to get that). Then perform a match of the library code against the binary. Using some heuristics we can narrow down the interesting code, eventually tinker with that.
So you must make sure, that nobody modifies the client. This can be done by scrambling the important parts of the binary and descramble them with a key, transmitted at runtime. You may choose the algorithm in a way, that you can use multiple different keys, which all produce a working code, but also have different results in a otherwise not executed section of the program. Now you need some debugger to get the code out of the program at runtime. You can hinder userspace debuggers but a kernel debugger cannot be fooled. So as a last resort you use the key dependent, otherwise unexecuted code section as P-box for a hash, that digests the in memory program image, sending back the digest to you. If that matches the one you expect you may send the data. But you still got the problem that someone could create a lookup table of all keys with all hash sums, so you add a random data sequence to, that would require to have at least a 2GiB table to cover all possibilities.
But you still missed one loophole: Someone could hook into OpenGL and catch all calls matching glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB[A], 256, 256, 0, GL_RGB[A], GL_[UN]SIGNED_BYTE, data), because this is the internal format of the images used by GE. You could scramble the images as well and use a register combiner or a shader to unscramble, but this gets broken, too.
In the end it just leaves one conclusion: Everything you send to another's computer is sooner or later open to his access.
But there is one easy solution, which would also leave us the option of having OSS clients: Visibly watermark the images with copyright notices of Google and the original image vendor. For a really professional use GoogleEarth lacks some important information, like used sensor, imaging parameters, type of image, projection, postprocessing and last but not least the date of aquisition.
I think I can safely claim, that 90% of the GE nonprofessional users use GE as a virtual sightseeing oportunity, 5% use it to have a nice picture of their home seen from above, 2% use it as a route planner (you cannot use it as a navigation system, but for that we got TomTom), and the rest, may do something seriously with it.
Personally if I really need accurate geoimagery I go to my university's geosciences department, log in with my user account and get the images in all flavours I can wish.
And one last thing: I could eventually do a
rm -r ~/.gaia ~/downloads/gaia-0.1.0*
but I definitely cannot to a
rm -r ${my_brain}/essentials_of_the_gaia_source_code
If I would like to I could reproduce the results of the Gaia insights within a few hours. And my client would probably look better than Gaia, too if someone considers the fact, that I - unintentionally though - once wrote a complete terrain rendering engine from scratch, complete with CLOD within 12 hours; unintentionally because I originally had a quadtree reducer in mind, but the data structure and algorithms just matched the needs of a terrain renderer to perfectly, once I got them written down.
I think Google is a great company, but OTOH I don't think it would be the right employer for me. I just have a too large urge for full disclousure; no one having intimate trade secrets would probably give me some job dealing with those secrets.
> The license we have to the imagery forbids us from allowing access
> from unofficial clients. The data providers take this very seriously
> indeed and noticed very quickly that such an application was out in
> the wild.
I must admit, that as soon as I read about Gaia you couldn't have counted to 1 until I fed wget with the URL. But instead of thinking about a Client replacement I was thinking more about a caching proxy, i.e. using the knowledge gatherd from reading the source to build a server, that the GE Client would mistake for the official one. Then using that tool, someone could download a given area where he might not have Internet access, working there using GE to makes nots about certain landmarks (e.g. if you're a geocacher).
Honestly I think Google - or Keyhole, the original developers of the software - is to blame for the whole mess. There is practically no protection in the protocol albeit a weak encryption scheme and a session cockie and probably access resticted to HTTP clients with a special client ID. Reverse Engineering? Is it reverse engineering if your aunty makes the best cookies in the world, won't give you the reciepe, but you may watch her as she bakes them, speaking out load the contents of the reciepe with the only protection being, that she calls flour "wheat millings" water "dihydroxylacid" and butter "processed milk residue".
What could have Google done to protect the data? First step: Encrypt the whole communication. Google Earth comes with OpenSSL but seemingly it is not used. Don't want the connection been made by an arbitrary client, then use HTTPS with a shared secrect. To make sure, nobody tinkers with the SSL library compile that statically into the program (LD_PRELOAD anybody?). In fact: Link everything statically. Now were at the point where really reverse engineering must be done, at least we have to disassemble the program (EULA forbids that, but lets just assume, an attacker ignores that). You can eliminate a lot of uncertanties by looking which third party libraries GE uses (is those are statically linkes have a look into licence.txt). Compile those libraries with the same compiler like the GE binary (look into the ELF header to get that). Then perform a match of the library code against the binary. Using some heuristics we can narrow down the interesting code, eventually tinker with that.
So you must make sure, that nobody modifies the client. This can be done by scrambling the important parts of the binary and descramble them with a key, transmitted at runtime. You may choose the algorithm in a way, that you can use multiple different keys, which all produce a working code, but also have different results in a otherwise not executed section of the program. Now you need some debugger to get the code out of the program at runtime. You can hinder userspace debuggers but a kernel debugger cannot be fooled. So as a last resort you use the key dependent, otherwise unexecuted code section as P-box for a hash, that digests the in memory program image, sending back the digest to you. If that matches the one you expect you may send the data. But you still got the problem that someone could create a lookup table of all keys with all hash sums, so you add a random data sequence to, that would require to have at least a 2GiB table to cover all possibilities.
But you still missed one loophole: Someone could hook into OpenGL and catch all calls matching glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB[A], 256, 256, 0, GL_RGB[A], GL_[UN]SIGNED_BYTE, data), because this is the internal format of the images used by GE. You could scramble the images as well and use a register combiner or a shader to unscramble, but this gets broken, too.
In the end it just leaves one conclusion: Everything you send to another's computer is sooner or later open to his access.
But there is one easy solution, which would also leave us the option of having OSS clients: Visibly watermark the images with copyright notices of Google and the original image vendor. For a really professional use GoogleEarth lacks some important information, like used sensor, imaging parameters, type of image, projection, postprocessing and last but not least the date of aquisition.
I think I can safely claim, that 90% of the GE nonprofessional users use GE as a virtual sightseeing oportunity, 5% use it to have a nice picture of their home seen from above, 2% use it as a route planner (you cannot use it as a navigation system, but for that we got TomTom), and the rest, may do something seriously with it.
Personally if I really need accurate geoimagery I go to my university's geosciences department, log in with my user account and get the images in all flavours I can wish.
And one last thing: I could eventually do a
rm -r ~/.gaia ~/downloads/gaia-0.1.0*
but I definitely cannot to a
rm -r ${my_brain}/essentials_of_the_gaia_source_code
If I would like to I could reproduce the results of the Gaia insights within a few hours. And my client would probably look better than Gaia, too if someone considers the fact, that I - unintentionally though - once wrote a complete terrain rendering engine from scratch, complete with CLOD within 12 hours; unintentionally because I originally had a quadtree reducer in mind, but the data structure and algorithms just matched the needs of a terrain renderer to perfectly, once I got them written down.
I think Google is a great company, but OTOH I don't think it would be the right employer for me. I just have a too large urge for full disclousure; no one having intimate trade secrets would probably give me some job dealing with those secrets.
