My Firefox extension is parsing big chunks of data. I would usually use WebWorkers to do this, however in XPCOM I seems that this is not an option. The ChromeWorker, https://developer.mozilla.org/en-US/docs/Web/API/ChromeWorker, seems to be obsolete and "discouraged in new projects".
Are there any options to use workers in a Firefox extension?
Short version: no, you cannot access XPCOM from a different thread. But that doesn't mean that you cannot use chrome workers.
Long version: Firefox used to allow accessing XPCOM from other threads, e.g. via ChromeWorker. This led to all kinds of issues like weird crashes or just plain inconsistent behavior. In the end Mozilla decided that supporting multithreaded XPCOM access was too complicated and error-prone, as was documenting its limitations and stopping people from shooting themselves in the feet.
With current Firefox versions, accessing XPCOM from ChromeWorker is no longer possible. ChromeWorker itself however isn't deprecated however even though the MDN comment can be easily misread as a general deprecation statement. The idea is that you would use ChromeWorker in combination with js-ctypes which will allow you to use native libraries (the ones provided by the operating system, libraries included in Firefox like NSS and libraries distributed with your extension) on a different thread.
Depending on what you are trying to achieve, this might work for you. E.g., if you need XPCOM for file access then you don't even need to use js-ctypes directly - OS.File API will do that for you. However, XPCOM access is limited to the main thread.
Related
Firefox provides XPCOM API interface for writing add-on classes in C++ and allow third-party web applications to access them. I'm wondering - is there any other way of achieving these benefits (i.e. write an add-on in C++ and provide a JavaScript interface, so any JavaScript app can use this interface and eventually C++ class functionality)?
Yes, it is possible to write XPCOM components in C++ (or Javascript for that matter) and expose them to websites. You would register them in the JavaScript-global-property, JavaScript-global-constructor, etc. category or categories.
This stuff is generally not documented very well, if at all. If you'd like to know more about it, then read the code (e.g. on mxr).
But doing so is strongly discouraged for a lot of reasons:
It is very hard to ensure such things are actually secure and make it work reliable.
It is hard to control what website may actually use the new API. JavaScript-global-property and friends will be available to all websites!
Your add-on would be introducing new names into the global javascript namespace, which might clash with web site code. (Because of this, many new WebAPIs aren't introduced directly into the global namespace, but are made a property of navigator).
Due to these reasons, the addons.mozilla.org site will only accept add-ons using this mechanism as an exception to the rule and only when the author demonstrates that the use is required and without real alternatives.
MDN has a couple of articles regarding webpage-to-extension communication and vice versa you could use instead, e.g. "Interaction between privileged and non-privileged pages".
Also, it is discouraged to ship binary XPCOM components within extensions:
You'd need to re-compile your binaries against each Gecko version (every six weeks), because binary components are version tagged since Firefox 4.
Binary APIs/ABIs between (point) releases are not as stable as you would hope. Actually APIs/ABIs where inadvertently broken late in the game quite often, causing lots of unnecessary crashes for a lot of users, e.g. bug 828296.
The platform developers officially said binary components in extensions are a hassle.
Instead, you should try to use Javascript where possible, and/or create a normal binary library (.so, .dll, .dylib) with a C-API/ABI and use js-ctypes. You could implement your XPCOM components in javascript, which would then call into your library with js-ctypes.
AFAIK most add-ons switched to js-ctypes by now.
I need your advices what to use - Layered Service Provider or just load mine DLL in all
process and hook necessary functions using, NCodeHook or EasyHook library.
This is needed for inspection of HTTP traffic.
P.S. This need to be done for commercial application
Thanks!
Before making a decision you need to consider the following:
Code hooking:
AV doesn't like code hooking, if you're using a library that has external DLLs, run a check with AV total before committing to it.
Make sure the library's license works for you, for example, for LGPL you won't be able to embed the library as static without becoming GPL yourself.
I heard people managed to hook Metro apps, it's something to investigate.
If you have another code hooking app, it may conflict.
LSP:
The default MS sample/installer is broken.
You may get something working on a VM or fresh install, but to get LSP working properly across all OS and browsers, will take 6-12 months.
Will not work with Metro apps.
In Komodia we use a combo of LSP/WFP for our SDK, knowing what I know now, if I'd go back 4 years, I'd use LSP all over again.
Good luck.
Using Easyhook will be a nice way to do it check the following http://www.sghaida.com/easyhook-for-systemcall-hooking/
I made an IE toolbar by BHO with C#. And now I want to make a firefox version.
I planned to use xul but it will show the source code to the user.
Seems DLL is not a good way in firefox.
I tried some toolbar like yahoo, google which will not create files in extension folder.
How can I make something like that?
(please see my note about obfuscation below)
It might not be the optimal way to develop a Firefox extension, but you can absolutely build them using an external DLL.
Before Gecko 2.0 you had to use the rather esoteric Mozilla build toolchain to include compiled code in your extensions.
js-ctypes to the rescue:
https://developer.mozilla.org/en/js-ctypes/Using_js-ctypes
https://developer.mozilla.org/en/js-ctypes/js-ctypes_reference
js-ctypes makes very easy work of loading external DLLs and binding their APIs to JavaScript functions.
You'll need to compile a few different versions of your DLL, and have your JavaScript correctly detect the platform and load the appropriate DLL, but it basically works the same for all platforms once you're back in JavaScript land.
ctypes.libraryName helps you determine the extension the DLL has on the current platform (e.g: .dll for windows, .so for Unix).
You can use other information (e.g: navigator.userAgent) to more concretely determine which sub-platform (e.g: Windows 7 64bit, or Vista 32bit).
Update:
There are a whole bunch of good reasons to included compiled DLLs in your extensions/applications (e.g: speed, special capabilities, 3rd party libraries), but if your sole purpose is obfuscation (hiding source code), then...
I wouldn't worry about it were I you. Technological means of anti-piracy won't get you very far in this modern world - if your software is good enough to get attention, someone will crack it.
I'd simply forget about it, and spend a little money on lawyers instead. (Copyright: yay! Patents: nay!)
Most applications created with Microsoft developer tools need some kind of runtime to be installed first.
However most viruses never need any kind of runtime to work. Also they also seem to use undocumented core/kernel APIs without have lib files etc.
So what runtime/application do most virus /virus writers use ?
If the runtime is statically linked in (as opposed to dynamically), then an EXE will be self-contained and you won't need a runtime DLL. However, really, you don't even need a runtime library at all if your code can do everything without calling standard library functions.
As for Windows APIs, in many cases you don't strictly need an import library either -- particularly if you load addresses dynamically via GetProcAddress. Some development tools will even let you link directly against the DLLs (and will generate method stubs or whatever for you). MS tries to ensure that names for documented API calls stay the same between versions. Undocumented functions, not so much...but then, compatibility typically isn't the foremost of concerns anyway when you're deliberately writing malicious software.
On Windows there a few libraries that allow you to intercept calls to DLLs:
http://www.codeproject.com/kb/system/hooksys.aspx
Is it possible to do this on Mac OS? If so, how is it done?
The answer depends on whether you want to do this in your own application or systemwide. In your own application, it's pretty easy; the dynamic linker provides features such as DYLD_INSERT_LIBRARIES. If you're doing this for debugging/instrumentation purposes, also check out DTrace.
You can replace Objective-C method implementations with method swizzling, e.g. JRSwizzle or Apple's method_exchangeImplementations (10.5+).
If you want to modify library behavior systemwide, you're going to need to load into other processes' address spaces.
Two loading mechanisms originally designed for other purposes (input managers and scripting additions) are commonly abused for this purpose, but I wouldn't really recommend them.
mach_inject/mach_override are an open-source set of libraries for loading code and replacing function implementations, respectively; however, you're responsible for writing your own application which uses the libraries. (Also, take a look at this answer; you need special permissions to inject code into other processes.)
Please keep in mind that application patching/code injection for non-debugging purposes is strongly discouraged by Apple and some Mac users (and developers) are extremely critical of the practice. Much of this criticism is poorly informed, but there have been a number of legitimately poorly written "plug-ins" (particularly those which patch Safari) that have been implicated in application crashes and problems. Code defensively.
(Disclaimer: I am the author of a (free) APE module and an application which uses mach_inject.)