Eolass patent bites the dust
Wednesday, 28. January 2009, 21:51:34
Some background:
Eolas (E) is a company that patented a certain way of interacting with embedded objects on web pages. This is why in Opera, you sometimes have to click (for example) a flash player to "activate" it before it can actually be controlled. That sucks.
Opera is the only browser that I know of, that currently have this annoying system in place. IE had it, but it reached to a pocket full of money to buy a license from E.
Other (open source) browsers don't implement this mechanism because E was kind enough to commit not to pursue legal actions against open source browsers that are violating its patent. Why? I guess because it wouldn't really be able to enforce that anyway. Builds without this future would pop up everywhere in no-time.
Solution:
Make a "custom" Opera build.
Now I look at it, finding out how to bypass this system took more time then it had to.
My starting point was to grab onto the string "Click to activate and use this control". It's displayed in status bar when hovering over non-activated embed.
It can be found in english.lng listed as:
-191213401="Click to activate and use this control"
Looks like Opera is using signed long's to identify strings. We can't just search for this number in opera.dll file and expect to find it there. Storing numbers as strings would be highly inefficient. Programs store numbers in hexadecimal instead so we have to convert this value to hex. Even windows calc will do the job in Scientific mode.
decimal -191213401 is 0xF49A50A7 in hex but we won't find that too in compiled file (even if we do, it won't be relevant to what we are looking for). PC's use little endian byte order so we have to search for reversed bytes: 0xA7509AF4, actually.
In a build I've been working on, this address was found twice in opera.dll. Those were the places where Opera actually referenced this string and as there were only two of those, it wasn't really hard to figure out that first one was the one I was looking for.
Found that out by setting a breakpoint in both of them and reloading a page that contained "non-activated" embed. Only one of those breakpoints triggered.
Tracing back from a code that references string, I eventually came to a code that created an "overlay" window. This is how Opera implemented "click-to-activate" thing. Invisible window is being positioned on top of non-activated embed and prevents interaction with it until clicked (when it is destroyed).
Cutting story short (I don't recall exact steps of this process as I've done that months ago - only some residual logs made this post possible), I've traced back again to find out where Opera decided to call CreateWindowEx function, that created our evil overlay. And below are the results of this work.
Patch:
For current versions of Opera (9.63, 10alpha) this change does the trick:
search: F7 D8 1B C0 F7 D8 C2 04 00 FF 74
replace: F7 D8 1B C0 B0 01 C2 04 00 FF 74
In 10alpha, search pattern can be found two times but only second one is relevant. First match might actually be completely unrelated thing that can fail in unexplained ways if you decide to replace it too. I took the risk. Multiple times. And nothing wrong happened.
Before hexediting opera.dll it has to be unpacked first. Use UPX command: "upx -d opera.dll"
For hex editing free XVI32 will do the job (not very friendly hexeditor though).
If you prefer to use a ready to go pack package download
opera-c2a-patch.zip
extract to Opera directory and run patch.bat.
PS. Solution is Windows only. I don't know of (nor used) any debugger on Unix so it would be hard for me to develop solution for it. And I'm not even near any Mac system so that would be even harder.
PS2. Pun intended in title ;>
Eolas (E) is a company that patented a certain way of interacting with embedded objects on web pages. This is why in Opera, you sometimes have to click (for example) a flash player to "activate" it before it can actually be controlled. That sucks.
Opera is the only browser that I know of, that currently have this annoying system in place. IE had it, but it reached to a pocket full of money to buy a license from E.
Other (open source) browsers don't implement this mechanism because E was kind enough to commit not to pursue legal actions against open source browsers that are violating its patent. Why? I guess because it wouldn't really be able to enforce that anyway. Builds without this future would pop up everywhere in no-time.
Solution:
Make a "custom" Opera build.
Now I look at it, finding out how to bypass this system took more time then it had to.
My starting point was to grab onto the string "Click to activate and use this control". It's displayed in status bar when hovering over non-activated embed.
It can be found in english.lng listed as:
-191213401="Click to activate and use this control"
Looks like Opera is using signed long's to identify strings. We can't just search for this number in opera.dll file and expect to find it there. Storing numbers as strings would be highly inefficient. Programs store numbers in hexadecimal instead so we have to convert this value to hex. Even windows calc will do the job in Scientific mode.
decimal -191213401 is 0xF49A50A7 in hex but we won't find that too in compiled file (even if we do, it won't be relevant to what we are looking for). PC's use little endian byte order so we have to search for reversed bytes: 0xA7509AF4, actually.
In a build I've been working on, this address was found twice in opera.dll. Those were the places where Opera actually referenced this string and as there were only two of those, it wasn't really hard to figure out that first one was the one I was looking for.
Found that out by setting a breakpoint in both of them and reloading a page that contained "non-activated" embed. Only one of those breakpoints triggered.
Tracing back from a code that references string, I eventually came to a code that created an "overlay" window. This is how Opera implemented "click-to-activate" thing. Invisible window is being positioned on top of non-activated embed and prevents interaction with it until clicked (when it is destroyed).
Cutting story short (I don't recall exact steps of this process as I've done that months ago - only some residual logs made this post possible), I've traced back again to find out where Opera decided to call CreateWindowEx function, that created our evil overlay. And below are the results of this work.
Patch:
For current versions of Opera (9.63, 10alpha) this change does the trick:
search: F7 D8 1B C0 F7 D8 C2 04 00 FF 74
replace: F7 D8 1B C0 B0 01 C2 04 00 FF 74
In 10alpha, search pattern can be found two times but only second one is relevant. First match might actually be completely unrelated thing that can fail in unexplained ways if you decide to replace it too. I took the risk. Multiple times. And nothing wrong happened.
Before hexediting opera.dll it has to be unpacked first. Use UPX command: "upx -d opera.dll"
For hex editing free XVI32 will do the job (not very friendly hexeditor though).
If you prefer to use a ready to go pack package download
opera-c2a-patch.zip
extract to Opera directory and run patch.bat.
PS. Solution is Windows only. I don't know of (nor used) any debugger on Unix so it would be hard for me to develop solution for it. And I'm not even near any Mac system so that would be even harder.
PS2. Pun intended in title ;>
ZAHEK, # 3. February 2009, 22:12:26