xaNoCTA – No Click-to-Activate (patch)

150 Replies to “xaNoCTA – No Click-to-Activate (patch)”

1. huh :insane: :insane: :insane: I’m not a programmer, but…Reason I asked is because I did get couple of times that click to activate msg on some sites lately (not on YT).I replaced one of the blocks in .pl file with what Ralf wrote couple of comments above (did noticed that before, but didn’t know what to do with it 😆 😆 ) and everything passed.Can you pls post couple of example sites, to check is it really working(sites that asking “click to activate” video)

2. @vux77: Ralf Onat has proposed a solution, ie a patch pattern, a few comments above.I have no real means to verify it, though, for now. Try it, if you dare! 😉 Or maybe other folks verify or refine the proposed patch.If there is enough certainty the patch works, I can include it in the “pre-manufactured” scripts hosted here.

3. any chance for x64 (Opera 12) version soon?

4. StackOverflow is your friend 🙂

5. Is there a free x64 disassembler-based debugger anywhere like OllyDbg?

6. In the meantime I have found a relevant piece of code in the x64 build of the latest stable 12.00 release.I still dont fully understand why it works, but it is analog to the patches in the x86 version. So if someone wants to try this out please report back. It essentially changes the “test eax, eax; setnz cl” to a “mov cl, 1; nop” which essentially removes CTA.Not sure about side effects. Please report back.
   {
   # contributors: PX
   desc => ‘Opera 12.00 64bit [1467]’,
   assert => undef,
   test => qr/x41xB8x01x00x00x00.{5}x33xC9x48x85xC0xb1x01x90x8BxC1x48x83xC4x38/,
   match => qr/(x41xB8x01x00x00x00.{5}x33xC9x48x85xC0)(x0Fx95xC1)(x8BxC1x48x83xC4x38)/,
   replace => ‘”$1xb1x01x90$3″‘
   },

7. Xeno! Thanks for your reply.You just have to SetWindowsHookEx(WH_CBT, CBTProc, hMod, 0) where the CBTProc function lies in a separate DLL of your program.When Opera tries to CreateWindowEx() your CBTProc will get called BEFORE, with a parameter HCBT_CREATEWND.From MSDN: If the hook procedure returns a nonzero value, the system destroys the window; the CreateWindow function returns NULL, but the WM_DESTROY message is not sent to the window. If the hook procedure returns zero, the window is created normally.So you can prevent the CreateWindowEx alltogether. I have tried this and you can successfully prevent the creation of for example the aPluginWindow window. But this does not seem to be the overlay, this rather seems to be the real flash window? If I prevent creation of this window then the rectangle where flash is supposed to be is just black.About the WndProc: No wndproc will be used/called since the window gets destroyed.An alternative approach would be (if there is NO overlay window): Use the same hook mechanism as above, catch the CreateWindowEx and then try to send a WM_LBUTTONDOWN to the window as soon as it is created, to mimic a user clicking the control without delay.

8. OK for anyone still on this:I have taken Opera for Windows 11.64 build 1403 and did a bit of fumbling with it.This is what I have come up with: http://www10.pic-upload.de/13.06.12/tx13ntrpd.pngShould be pretty self explanatory. Id love to hear what the others are saying if some of my finding are correct and maybe help to answer the questions I asked 2 posts above.

9. Ralf, I read your earlier comment and think about it, when I find the time. ;)(First thought: How would you prevent creating the overlay window? You probably cannot return an error, so you have to ignore. Then what happens with the window’s WndProc, what’s the WndProc? Will it catch mouse clicks anyways (I think there was an issue like that)? Will it at times try to destroy the non-existing window?).But many thanks for your interest! (That png is huuuge. 😉 )

10. Guys, thank you for this. I just hope you make it available for the up coming Opera v. 12.00 and later too.

11. After using Opera for so long I only now stumbled upon this blog in finding a way to ease the “click to activate” pain.I have read all the info and posts here and have to say a big thank you to everyone involved in making this patch possible. I am somewhat of a developer myself, however my asm is severely lacking.So I was curious as to how this patch really works. As Xeno explained there is a function taking 3 parameters (17,0,1) where you modify the return value to 1 by changing the parameter 2 from 0 to 1. Is there any insight as to why this changes the behavior of the click to activate and how this is related?The reason I ask is the following: I have read on multiple locations here that a CreateWindowEx is used to capture the first click and to enable the control. If it really is a CreateWindowEx call that just needs to be prevented, then I have a much simpler approach: You could set a Windows hook and wait for a call to create this special overlay by Opera and simply prevent it. That would mean you have to run a 1MB app to monitor the calls, but you would (theoretically) never have to change a dll anymore, even after new versions.I have tried looking for the overlay Window, but all I can find is the flash plugin window itself (Class Name: aPluginWinClass)If someone could help here and given that it works that way, I could produce a working test app with source in a matter of moments.Thanks

12. Well,I wish the patch of x64 will also be created before long.:)

13. Searching for “push 0; push 17” (apparently the arguments passed to called subroutine have been swapped) in build 1387 and then setting breakpoints on the more plausible occurrences leads me to the same location you found, Robin:
    Address Hex dump Command Comments
    6778AE33 /$ 56 push esi ; Opera_dll.6778AE33(guessed Arg1)
    6778AE34 |. 8B7424 08 mov esi,[dword ss:arg.1]
    -6778AE38 | 6A 00 push 0 ; // 17 2B0 (!!!)
    +6778AE38 6A 01 push 1 ; // 17 2B0 (!!!)
    6778AE3A |. 6A 17 push 17 ; Arg2 = 17
    6778AE3C |. 68 B0020000 push 2B0 ; Arg1 = 2B0
    6778AE41 |. E8 3E34ACFF call Opera_dll.6724E284
    6778AE46 |. 5E pop esi
    6778AE47 . C2 0400 retn 4
    6778AE4A /$ 56 push esi ; Opera_dll.6778AE4A(guessed Arg1)
    6778AE4B |. 8B7424 08 mov esi,[dword ss:arg.1]
    -6778AE4F | 6A 00 push 0 ; // 17 2AE (!!!!)
    +6778AE4F 6A 01 push 1 ; // 17 2AE (!!!!)
    6778AE51 |. 6A 17 push 17 ; Arg2 = 17
    6778AE53 |. 68 AE020000 push 2AE ; Arg1 = 2AE
    6778AE58 |. E8 2734ACFF call Opera_dll.6724E284
    6778AE5D |. 5E pop esi
    6778AE5E . C2 0400 retn 4
    Calling Opera_dll.6724E284 with 1 instead of 0 (similar to what the previous patches did) gives an empirically pleasing result. 🙂 You’re right.Another idea was to force the argument passed to Opera_dll.6724E284 and passed along therein in that function only:
    6724E284 /$ FF7424 08 push [dword ss:arg2] ; ÚArg4 => [Arg2], !!!!!!!!!!!!!!!!!!!!! core
    -6724E288 |. FF7424 10 push [dword ss:arg3] ; ³Arg3 => [Arg3]
    +6724E288 6A 01 push 1
    +6724E28A 90 nop
    +6724E28B 90 nop
    6724E28C |. 6A 01 push 1 ; ³Arg2 = 1
    6724E28E |. FF7424 10 push [dword ss:arg1] ; ³Arg1 => [Arg1]
    6724E292 |. E8 49FC0400 call Opera_dll.6729DEE0 ; ÀOpera_dll.6729DEE0
    6724E297 |. F7D8 neg eax
    6724E299 |. 1BC0 sbb eax,eax
    6724E29B |. F7D8 neg eax
    6724E29D . C2 0C00 retn 0C
    But that would probably counter the attempt to keep patches similar or even unified over versions…ETA: Apparently working, but not-unified, patch in BitBucket-repository…

14. I think I may have found (in a last ditch effort before throwing in the towel) the new location using my usual semi-educated fumble in the dark with modified regexes method, but I’d like someone more educated to take a look before I commit to making a new match pattern that works on all the broken builds.This applies to build 12.00.1387 x86 (I think all the patches would need to be re-engineered from scratch for x64)In your hex editor of choice go to address 0x0060A238. You should find a “6A 00 6A 17” pattern, and again not long after at 0x0060A24F. Change both 00 values to 01 (i.e. the same patch idea as before) and see how it goes.I’m using it with this applied and I’m not getting the click-to-activate behaviour, which seems a good sign I’ve not changed the wrong thing, but I still think it’s good to be paranoid.

15. It hasn’t been working for the past couple of builds. Please fix it. Thanks in advance.

16. I myself don’t experience issues you describe with 1328. (But 1351 w/ OOPP in contrast is unusably instable.)On the other hand, it is perfectly possible that there are undesired side effects with the patch.I have also have such a suspicion: With many tabs open (perhaps 80+) after a while of “heavy surfing” images (the larger the sooner) fail to render, then even app icons in the “open with…” menu fall back to Window’s default app ichon (blue framed white window). If you insist opening more tabs or visit more pages, the time will come where Opera crashes. To me that tastes like some handles or other resources going out of stock.But it is not exactly proportional to flash content embedded in the tabs, I suspect. So it’s probably *not* related to CTA (with its invisible overlay windows, whose creation should be inhibited in the first place by this patch). It is perhaps more related to the purportedly fixed 3025 background images bug CORE-42565.

17. And that can go on indefinitely, since when isn’t there another place to appeal to, but it does say “in the meantime Eolas won’t be able to go after new targets.” Was Opera ever actually named in this? If not, they’re not an old target, so….

18. Eolas still has time to appeal the decision and such. It will probably still be a while before it is legally safe to remove click-to-activate.

19. Regardless, I bet it’s still not added back into Opera.

20. Originally posted by gwarser:http://www.wired.com/threatlevel/2012/02/interactive-web-patent/:hat:

21. Click to activate Broken in build 12.00.1301Further modified the first match pattern to un-break it. Seems to be working nicely, and seems to match the same older files[1] perfectly too.test => qr/x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{4}(?:xF7xD8x1BxC0xF7xD8)?[x5Fx5E]xC2x04x00.{5}x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{4}(?:xF7xD8x1BxC0xF7xD8)?[x5Fx5E]xC2x04x00/,
    match => qr/x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{4})((?:xF7xD8x1BxC0xF7xD8)?[x5Fx5E])xC2x04x00(.{5})x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{4})((?:xF7xD8x1BxC0xF7xD8)?[x5Fx5E])xC2x04x00/,
    replace => ‘”x6Ax17x6Ax01x6Ax01$1xE8$2$3xC2x04x00$4x6Ax17x6Ax01x6Ax01$5xE8$6$7xC2x04x00″‘[1] I did some very heavy duty batch testing recently with my full collection of DLLs looking at exactly which patterns matched which builds (though not testing whether the match was genuine). The results are mostly useless, but did allow me to quickly make sure nothing broke with the changed patch above. The matches are numbered top-to-bottom (ignoring the commented patch in CTA) in the order they’re currently found in the individual .pl files. You can control the highlighting by editing cells F1, G1, and H1

22. http://www.wired.com/threatlevel/2012/02/interactive-web-patent/

23. It would be nice if someone made a patch that removes the search option that is shown in the address bar’s drop down menu.

24. Any working solution for the Linux version of Opera? Thanks.

25. It’s worth noting that the Perl work is all by XenoAntares, whose blog this is. My only contributions have been new regular expressions; I only have a small amount of knowledge when it comes to Perl.Learning Perl would be useful, what’s far more important is learning regular expressions. Without those there’s pretty much no hope of making a good generic patch. You could write your own executable designed specifically for applying this patch, but it would inevitably end working in a similar fashion to a regular expression engine — and why reinvent the wheel.[1]Perl as a language has probably done the most with regular expressions. Many of the tokens used in matches would have first appeared in Perl, so learning both together might not be a bad idea. And if you can handle debugging assembler Perl should be well within you range. :P[1] Regular expressions, alongside the Xpath bindings in JavaScript, rank highly on my list of “Holy crap this is awesome” useful things.

26. Hi? Robin Zalek! I have found a way to extract opera.dll from distribution by the plugin for Total Commander, and have downloaded a collection of snapshots on the site http://arc.opera.com/snapshot/windows/. Also, I’m starting to learn Perl.

27. Hi,Unfortunately I only have the installer files because I happened to make the decision way back in the 9.50 days to keep copies of every snapshot released. At the time I had no real reason to do so, other than the fact it wasn’t taking up much hard drive space — I actually have ~2.5 GiB of Opera installers now.Even if I take just the DLLs from since Opera switched to using the 7-zip based installer (which was only a few builds before they introduced the new address bar) they still total over 1 GiB, and even when compressed as heavily as possible into a solid 7-zip archive still take up around 150 MiB which is more than I can easily upload and distribute.I could setup a torrent, but right now it’d only be available for about 10 hours or so, then I have plans which involve my laptop coming with me. If you’re interested, and keep an eye on the comments here I’ll upload a .torrent file some time late on Sunday (GMT) which will be both the installers, so you can test patches, and the extracted DLLs so you can easily search the entire collection with regular expressions.I’ve actually already read with interest your recent (Google translated) post on the original thread about how you found the patch originally. It’s nice to understand how the patch actually works, which I didn’t before. I only have a passing knowledge of assembler and wouldn’t even have known where to begin if you hadn’t provided the patches you have.In case you didn’t notice it above my notes should make interesting reading, although they’re not especially well commented. Especially the part that shows what I believe to be the correct matches (I did not test all 97 versions, but I did test a random selection from those 97) for every build. I especially have not tested the 11.00.1094 – 11.00.1136 because their patterns differ substantially from all later builds, they are also before you produced your first patch.I’ll quickly break down my logic for the regular expression I use:xDDx05 [The FLD, this is the part we need to change]
    ( [The rest of the regex is only used to make sure we’re matching the correct instance so I capture the whole lot for the replacement]
    .{3}x67 [The address for the FLD, the x67 has been consistent across all versions]
    (?:[x89x8B].x24.)? [MOV, Fairly changeable between builds, and does not exist in all builds, entire block is optional]
    xD9xBCx24.x00{3} [FSTCW (so OllyDbg tells me), consistent in all builds but the earliest four, the . could be replaced with [x8Cx94] and still match every version]
    (?:[x89x8B].x24.)? [MOV, Again, very changeable, and does not exist in all builds, block is again optional]
    x0FxB7x84x24.x00{3} [This is the first perfectly consistent match after the xDDx05 that we are aiming to patch. The x0FxB7x84x24 exists in all but the earliest four builds, again the . could currently be reliably replaced with [x8Cx94] and still match]
    )
    And of course at the bottom of the file there’s the unused, untested, unoptimised regex that matches every single build since they changed the address bar. Which I only kept for my own curiosity, and maybe the curiosity of others.Currently your patterns would match all versions (not counting the six early versions) except 11.60.1150 (DD ?? ?? ?? ?? 67 89 54 24 4C). I’m not sure if you’d generate false positives with any of those though. This is why I prefer matching until the 0F B7 84 24 because this has been totally consistent, and the shorter the match pattern the more likely to find false positives in other builds; I think when I attempted to match only as far as the D9 BC 24 ?? 00 00 00 part I was still finding false positives.

28. Hello, Robin Zalek! I am the author of the patch, disabling highlight the domain in the address bar. I want to try to make own universal patch, but for this I need all the original files opera.dll releases from ver 11.10. Could you put them in a single archive filehosting, if you have enough traffic, or suggest a way to quickly download all the required distributions and extraction of the file opera.dll. Thank you!PS. Now I use 3 patterns to search and replace DD -> D9:DD ?? ?? ?? ?? 67 D9 BC 24 ?? 00 00 00 DD ?? ?? ?? ?? 67 8B 54 24 1CDD ?? ?? ?? ?? 67 89 54 24 50

29. Robin: Thanks for getting that plugin to work on the newest snapshot. 🙂

30. So I spent some time with Nibiru’s address bar patch.First on the versions specifically listed at the site linked before (which helpfully included one for the latest 12.00 beta.) After much tweaking of the regex, expanding and contracting the scope I found a pattern with matched all those DLLs but only in the right place. Then I expanded the scope to every DLL from every build since the introduction of the 7z installer.Eventually I managed to find a match that hit reliably for the last 97 publicly released builds (from 11.10.1140 onwards.) The only real problem is that I don’t actually understand why Nibiru’s patch works, although it clearly does. 😛 Looking at the disassembly in OllyDbg doesn’t show any difference that I can spot between before and after code.I haven’t tested in every single one of those 97 builds, but I have tested several random builds from that set and found no problems. With luck this pattern should endure for some time.Patch (as plugin)Notes made while testing——————————————————————————————————————————————And more for the curious. I decided to hunt down the post for .1140 to see whether there was a particular reason for the blackout prior to this version. Before I can find it I stumble across the post for .1094 which is clearly the introduction of the address bar changes. Only 6 more DLL matches and I have a complete set. :PLong story short, the notes above do include a “perfect” regex. But it’s overkill. There’s two basic variants in 97 builds, but those 6 extra builds add two very different variants which may not even be right — I didn’t test. But I just couldn’t leave it without trying to find them.

31. OMG! Thank you so much!! ))

32. Thanks for fixing the plugin. I hope that you have a merry Christmas and New Year.

33. I’m not using the new 11.61.1222 build, but I’ve just tested it.My revised pattern above works for the click-to-activate patch.The User JS patch breaks, the JNE SHORT has changed slightly.Revised patch, which just ignores the operand in both the jumps (they get NOP’d anyway):# Silent UJS HTTPS patch by XA, based on version of Dither
    # contributors: XA, Dither
    desc => ‘Silent HTTPS UserJS (Method 3) Opera 11.60 [1147,11,50,1159..], Opera 12.00 [1159,..]’,
    assert => undef,
    test => qr/x90{12}xA1.{4}x89x98.{4}x43x90x89x98.{4}x4Bx90x56/,
    match => qr/x56xFFxB7.{4}xE8.{4}(xA1.{4})x39(x98.{4})x75.x39(x98.{4})x74.x56/,
    replace => ‘”x90x90x90x90x90x90x90x90x90x90x90x90$1×89$2x43x90x89$3x4Bx90x56″‘Edit: Bryan’s post totally wasn’t there when I originally loaded the page. 😛

34. The included plugin doesn’t work on the new snapshot of 11.61.

35. Looks like a clever approach, Robin. Thanks for your contribution!

36. Robin: Thanks for making it work with the new snapshot. 🙂

37. New match pattern for no click-to-activate, essentially a more generic version of the 1184/1191 patch.# contributors: XA [20111207], BtEO [20111219]
    desc => ‘Opera 12.00 [1085,1090,1105,1116,1155,1174,1191,1231], 11.60 [1134,1139,1144,1145,1147,1150,1159,1163,1169,1173,1177,1178,1180,1181,1184,1185]’,
    assert => undef,
    test => qr/x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{2}(.{2})xF7xD8x1BxC0xF7xD8[x5Fx5E]xC2x04x00.{5}x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{2}1xF7xD8x1BxC0xF7xD8[x5Fx5E]xC2x04x00/,
    match => qr/x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{2})(.{2})xF7xD8x1BxC0xF7xD8([x5Fx5E])xC2x04x00(.{5})x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{2})3xF7xD8x1BxC0xF7xD8([x5Fx5E])xC2x04x00/,
    replace => ‘”x6Ax17x6Ax01x6Ax01$1xE8$2$3xF7xD8x1BxC0xF7xD8$4xC2x04x00$5x6Ax17x6Ax01x6Ax01$6xE8$7$3xF7xD8x1BxC0xF7xD8$8xC2x04x00″‘Notes:* 12.00.1085 was the last non-trivial break, and this pattern matches every 11.60/12.00 build since then. (I knew there was a reason I’ve kept copies of possibly every single snapshot since 9.50 :P)* The CALL in both locations should go to both to the same function, so the address matched should be nearly identical (besides a difference in offset by 31 bytes) between them. The pattern above matches in the first location as (.{2})(.{2}) and in the second location as .{2}3 — the idea being that the top two bytes of the offset are unlikely to change and just adds a further sanity check in case of a false positive appearing. I recognise this is almost certainly overkill, and may unnecessarily fail in new builds whilst still not being a total guarantee against false positives. Currently omitting the backreferences yields no false positives on any 11.60/12.00 build. Here’s that version of the pattern:# contributors: XA [20111207], BtEO [20111219]
    desc => ‘Opera 12.00 [1085,1090,1105,1116,1155,1174,1191,1231], 11.60 [1134,1139,1144,1145,1147,1150,1159,1163,1169,1173,1177,1178,1180,1181,1184,1185]’,
    assert => undef,
    test => qr/x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{4}xF7xD8x1BxC0xF7xD8[x5Fx5E]xC2x04x00.{5}x6Ax17x6Ax01x6Ax01[xBFx68].{4}xE8.{4}xF7xD8x1BxC0xF7xD8[x5Fx5E]xC2x04x00/,
    match => qr/x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{4})xF7xD8x1BxC0xF7xD8([x5Fx5E])xC2x04x00(.{5})x6Ax17x6Ax00x6Ax01([xBFx68].{4})xE8(.{4})xF7xD8x1BxC0xF7xD8([x5Fx5E])xC2x04x00/,
    replace => ‘”x6Ax17x6Ax01x6Ax01$1xE8$2xF7xD8x1BxC0xF7xD8$3xC2x04x00$4x6Ax17x6Ax01x6Ax01$5xE8$6xF7xD8x1BxC0xF7xD8$7xC2x04x00″‘

38. It doesn’t work with the new Opera 12 snapshot.

39. I’ve decided to switch entirely to the ”pluggable“ branch soon.Here is a version, that includes a patch suitable for Opera 12.00 builds 1184 and 1191: xa-nocta_pluggable.zip.For those interested: It patches both locations mentioned by BtEO above, but in an other way than all the patches before. The pattern is quite specific, so it will probably break ”soonish“.The function called (not only) in these two locations is called with 3 or 4 parameters, three on the stack, one in EDI. It seems scan a (somehow compactly packed) map for an item, whose id is specified in EDI. This item is never found – possibly at least up until a CTA message appears in an unpatched session.If it was found, however, skipping some details, an item with a type or id given by arg3 (= 17) is examined in an referenced structure. If an item with that id is not to be found, arg2 (= 0) is returned as a fallback.This latest patch approach modifies, what is passed to that function for a fallback value, ie it pushes 1 instead of 0 as arg2.

40. Its not working in the latest snapshot of Opera 12.

41. I had little time and stuck with the 11.60 series for the time being. Thanks for posting your findings.You mention a valid point. I think, eternal compatibility and true universal coverage of all versions will be difficult to promise – if not only due to the fact, that it meant to test against all former versions (or do better (context) documentation). Luckily enough, the BitBucket repository allows for cherry-picking development snapshots.That said, the “assert” clause could be employed here…

42. I’ve taken a look at the patch in 12.00.1174Here’s the relevant code:There are two instances right next to each other, with the difference (both between the two instances, and between builds) marked in red.In 1155 the second instance is patched, and making the same change in 1174 works; curiously however patching either or both instances seems to work. Though I’ve didn’t run Opera for any longer than it took to test the click to activate was removed to see if any instability was introduced by patching the first instance. This is relevant because if we update the patch as it stands to match A3 as well as A0 and A1 then it would have matched the first instance in 1155 (and possibly future builds) instead of the second.For this reason I’m not suggesting a new match pattern as Xeno might know better than me (or not) the implications of patching the wrong instance.

43. I’m sure you don’t want to hear this, but 12.00.1174 breaks it again. I wonder why it changes so much more often these days?

44. Works for me. Do you have the latest version?

45. Hi Mr Kirk.I’m afraid I cannot promise that one. I apologize.You know, the whole idea of introducing a plugin structure to xaNoCTA was to allow for special interest and pet patches to be easily applied to Opera without leaving the burden of providing long term maintenance on my shoulders.The ”UserJS on HTTPS“ warning is an issue annoying me severely enough to motivate me caring about the related plugin (which happens to be the sample plugin).Personally I do not really care* about the ”Addressbar host highlightning“ thingy, so I probably won’t maintain a plugin patching that one. But feel encouraged to do that yourself! Or maybe the original author/s (supposed to be Nibiru on operafan.net) want to provide that plugin?__* I quite like the custom setup opera:config#UserPrefs|HideURLParameter=0 (together with the default opera:config#UserPrefs|ShowFullURL=0)

46. So, can you please get the “No Addressbar host highlightning patch” plugin to work on the latest snapshot? Thanks in advance.

47. Ok. Well, I hope someone gets it working.

48. An updated xa-nocta-plugin-00.pl can be found in pluggable branch(!) in the bitbucket repository.

49. Okay, think I got it.ebx should be restored to zero after we incremented it to store the ack(?)-flag. It will be used as const zero further on. CPU Disasm
    Address Hex dump Command Comments
    67671770 33C0 xor eax,eax
    67671772 8987 D4200000 mov [dword ds:edi+20D4],eax
    67671778 3BC3 cmp eax,ebx
    6767177A 74 5F je short Opera_dll.676717DB
    -6767177C 56 push esi ; ÚArg2
    +6767177C 90 nop
    -6767177D FFB7 D4200000 push [dword ds:edi+20D4] ; ³Arg1
    +6767177D 90 nop
    +6767177E 90 nop
    +6767177F 90 nop
    +67671780 90 nop
    +67671781 90 nop
    +67671782 90 nop
    -67671783 E8 C1F31500 call Opera_dll.677D0B49 ; ÀOpera_dll.677D0B49, !!!!!!!!!!!!!!!
    +67671783 90 nop
    +67671784 90 nop
    +67671785 90 nop
    +67671786 90 nop
    +67671787 90 nop
    67671788 A1 1042E267 mov eax,[dword ds:Opera_dll.67E24210]
    -6767178D 3998 CC200000 cmp [dword ds:eax+20CC],ebx
    +6767178D 8998 CC200000 mov [dword ds:eax+20CC],ebx
    -67671793 75 4E jne short Opera_dll.676717E3 ; jump if flagUJSModified == 1
    +67671793 43 inc ebx
    +67671794 90 nop
    -67671795 3998 D0200000 cmp [dword ds:eax+20D0],ebx
    +67671795 8998 D0200000 mov [dword ds:eax+20D0],ebx
    -6767179B 74 06 je short Opera_dll.676717A3 ; jump if flagUJSonHTTPSack == 0
    +6767179B 4B dec ebx
    +6767179C 90 nop
    6767179D 56 push esi ; ÚArg1
    6767179E E8 9FBC1000 call Opera_dll.6777D442 ; ÀOpera_dll.6777D442
    676717A3 A1 1042E267 mov eax,[dword ds:Opera_dll.67E24210]
    676717A8 3998 D0200000 cmp [dword ds:eax+20D0],ebx
    676717AE 0F85 B4DEC9FF jne Opera_dll.6730F668
    676717B4 E9 ABDEC9FF jmp Opera_dll.6730F664

    ————————————————————————–

    That leads to binary pattern @6767177c in memory / @00420b7c file (Opera 11.60 build 1147):

    match: 56 FF B7 D4 20 00 00 E8 C1 F3 15 00 A1 10 42 E2 67 39 98 CC 20 00 00 75 4E 39 98 D0 20 00 00 74 06 56
    replace: 90 90 90 90 90 90 90 90 90 90 90 90 A1 10 42 E2 67 89 98 CC 20 00 00 43 90 89 98 D0 20 00 00 4B 90 56

50. The same approach as took the previous “UserJS warning when used on HTTPS” patch does produce an access violation with me.Here are my superficial research results:
    CPU Disasm
    Address Hex dump Command Comments
    67671770 ³> À33C0 xor eax,eax
    67671772 ³> 8987 D4200000 mov [dword ds:edi+20D4],eax
    67671778 ³. 3BC3 cmp eax,ebx
    6767177A ³.↓ 74 5F je short Opera_dll.676717DB
    -6767177C ³> 56 push esi ; ÚArg2
    +6767177C 90 nop
    -6767177D ³. FFB7 D4200000 push [dword ds:edi+20D4] ; ³Arg1
    +6767177D 90 nop
    +6767177E 90 nop
    +6767177F 90 nop
    +67671780 90 nop
    +67671781 90 nop
    +67671782 90 nop
    -67671783 ³. E8 C1F31500 call Opera_dll.677D0B49 ; ÀOpera_dll.677D0B49, !!!!!!!!!!!!!!!!!!!!!!!!!!!
    +67671783 90 nop
    +67671784 90 nop
    +67671785 90 nop
    +67671786 90 nop
    +67671787 90 nop
    67671788 ³. A1 1042E267 mov eax,[dword ds:Opera_dll.67E24210]
    -6767178D 3998 CC200000 cmp [dword ds:eax+20CC],ebx
    +6767178D 8998 CC200000 mov [dword ds:eax+20CC],ebx
    -67671793 ↓ 75 4E jne short Opera_dll.676717E3
    +67671793 43 inc ebx
    +67671794 90 nop
    -67671795 3998 D0200000 cmp [dword ds:eax+20D0],ebx
    +67671795 8998 D0200000 mov [dword ds:eax+20D0],ebx
    6767179B ³.↓ 74 06 je short Opera_dll.676717A3
    6767179D ³. 56 push esi ; ÚArg1
    6767179E ³. E8 9FBC1000 call Opera_dll.6777D442 ; ÀOpera_dll.6777D442
    676717A3 ³> A1 1042E267 mov eax,[dword ds:Opera_dll.67E24210]
    676717A8 ³. 3998 D0200000 cmp [dword ds:eax+20D0],ebx
    676717AE ³.↑ 0F85 B4DEC9FF jne Opera_dll.6730F668
    676717B4 ³.↑ E9 ABDEC9FF jmp Opera_dll.6730F664

    ————————————————————————–

    That leads to binary pattern @6767177c in memory / @00420b7c file (Opera 11.60 build 1147):

    match: 56 FF B7 D4 20 00 00 E8 C1 F3 15 00 A1 10 42 E2 67 39 98 CC 20 00 00 75 4E 39 98 D0 20 00 00 74 06 56
    replace: 90 90 90 90 90 90 90 90 90 90 90 90 A1 10 42 E2 67 89 98 CC 20 00 00 43 90 89 98 D0 20 00 00 74 06 56

Comments are closed.