> 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
I just want to remind you of the "Deep Space 1" probe, which is the very first utilizing a ion drive. The thrust isn't much, but a ion engine can run over a long period, allowing much higher "burnout" velocities, than the chemical rocket engines that are neccesary to launch a rocket. And it has a power of only 1kW. IMHO such powerfull engines make most sense at solar swingby manouvers where you've a lot of light energy avaliable.
On earth it's the best to burn the whole fuel in a very short time(*) but in zero g this doesn't matter.
* think about, what happens, when you reduce the thrust so much, that the rocket would just levitate. You burn and burn fuel, but don't gain speed. But burning the same fuel in a short time gives you a lot of speed.
Take this serious? Sorry, but after a triple feature matrix session at saturday night I'm only able to take it with humor.
BTW: The M$ guys seem to have a very interesting sense of humor though. IE, FrontPage, WYSIWYG, COM, ActiveX, DirectX, ASP, IIS, SMB, FAT, NTFS, defrag.exe, Access, MFC, ATL, pascal calling in the API, Drive Letters...
The Blue Pill is that fat, I had no idea? Sure, and as it semms a runable WinXP must then fits onto a floppy disk, since the blue pill definitely does;-)
Hhm, I get my best Ideas when releasing the ballast. And since I carry my laptop everywhere with me it also goes with there.
I've no girlfriend (yet), however the problem is not unfamiliair with me. When it had come, that we were moving to another appartment I decided to stuff all my stuff into a small room that only I'm allowed to enter. But I installed also a CAT5 point in the living room at a secret position;-)
Slashdot Mirror
> 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
I just want to remind you of the "Deep Space 1" probe, which is the very first utilizing a ion drive. The thrust isn't much, but a ion engine can run over a long period, allowing much higher "burnout" velocities, than the chemical rocket engines that are neccesary to launch a rocket.
And it has a power of only 1kW. IMHO such powerfull engines make most sense at solar swingby manouvers where you've a lot of light energy avaliable.
On earth it's the best to burn the whole fuel in a very short time(*) but in zero g this doesn't matter.
* think about, what happens, when you reduce the thrust so much, that the rocket would just levitate. You burn and burn fuel, but don't gain speed. But burning the same fuel in a short time gives you a lot of speed.
Take this serious? Sorry, but after a triple feature matrix session at saturday night I'm only able to take it with humor.
BTW: The M$ guys seem to have a very interesting sense of humor though. IE, FrontPage, WYSIWYG, COM, ActiveX, DirectX, ASP, IIS, SMB, FAT, NTFS, defrag.exe, Access, MFC, ATL, pascal calling in the API, Drive Letters...
The Blue Pill is that fat, I had no idea? Sure, and as it semms a runable WinXP must then fits onto a floppy disk, since the blue pill definitely does ;-)
Cypres Semicon has a Intel 8051 compatible Microcontroller AN2131 that also provides a complete Full Speed USB interface.
Hhm, I get my best Ideas when releasing the ballast.
;-)
And since I carry my laptop everywhere with me it also goes with there.
I've no girlfriend (yet), however the problem is not unfamiliair with me. When it had come, that we were moving to another appartment I decided to stuff all my stuff into a small room that only I'm allowed to enter. But I installed also a CAT5 point in the living room at a secret position