Calling COM objects from a Firefox addon - firefox

I'm about to take on a project that requires a Firefox addon to issue call to COM dll's installed on the client Windows machine and I'm having a hard time estimating the complexity of this undertaking.
I have quite a bit of experience with COM, so I'm not frightened by it. I have less experience with Firefox addons, but I don't think that's where my problems are going to be.
Has anybody done anything like that?
Does Firefox allow its addons to communicate freely with the outside world?
Is there a plugin or sample code somewhere that does something like this (Google turned up little useful results)?
Update: Naturally, I would prefer a solution that doesn't require building an extension in C++, if that's at all possible.

Create an XPCOM in C++ to talk to your COM objects as usual. The XPCOM extensions can then be made available to Javascript to do the rest of the extension (GUI mainly, I guess). However, that's about all I understand about it :-)

You might be interested by IE Tab extension, which is open source. I haven't looked but I guess it does Com access to use IE's display.

If you do this you'll almost certainly need to use XPCOM. Take a look at Shanti Rao's JSDB, which supports COM/ActiveX within Javascript. The ActiveX stuff is in a file called wrap_com.cpp. It supports most IDispatch interfaces; the Invoke method of IDispatch is the magic that makes this work.
How complex this is depends on how "easy" you want this to be from Javascript. If you implemented an XPCOM thing called IDispatchObject where you had to pass in the names of methods & an array of arguments, then it's probably not too hard. If you want to create a general method for doing dynamic bindings to COM objects & referring to them directly, then that's tougher... not sure if the techniques used in JSDB will carry over to XPCOM.

Related

Windows: How to intercept Win32 disk I/O API

On Windows, all disk I/O ultimately happens via Win32 API calls like CreateFile, SetFilePointer, etc.
Now, is it possible to intercept these disk I/O Win32 calls and hook in your own code, at run time, for all dynamically-linked Windows applications? That is, applications that get their CreateFile functionality via a Windows DLL instead of a static, C library.
Some constraints that I have are:
No source code: I won't have the source code for the processes I'd like to intercept.
Thread safety: My hook code may dynamically allocate its own memory. Further, because this memory is going to be shared with multiple intercepted processes (and their threads), I'd like to be able to serialize access to it.
Conditional delegation and overriding : In my hook code, I would like to be able to decide whether to delegate to the original Win32 API functionality, or to use my own functionality, or both. (Much like the optional invocation of the super class method in the overriding method of the subclass in C++ or Java.)
Regular user-space code: I want to be able to accomplish the above without having to write any device-driver, mainly due to the complexity involved in writing one.
If this is possible, I'd appreciate some pointers. Source code is not necessary, but is always welcome!
You may want to look into mhook if Detours isn't what you want.
Here are a couple of problems you may run into while working with hooks:
ASLR can prevent injected code from intercepting the intended calls.
If your hooks are global (using AppInit_DLLs for example), only Kernel32.dll and User32.dll are available when your DLL is loaded. If you want to target functions outside of those modules, you'll need to manually make sure they're available.
I suggest you start with Microsoft Detours. It's free edition also exists and its rather powerful stable as well. For injections you will have to find which injection method will work for your applications in target. Not sure whether you need to code those on your own or not, but a simple tool like "Extreme Injector" would serve you well for testing your approaches. And you definitely do not need any kernel-land drivers to be developed for such a simple task, in my opinion at least. In order to get the full help of me and others, I'd like to see your approach first or list more constraints to the problem at hand or where have you started so far, but had problems. This narrows down a lot chit-chats and can save your time as well.
Now, if you are not familiar with Detours from Microsoft (MSFT) please go ahead and download it from the following link: http://research.microsoft.com/en-us/projects/detours/ once you download it. You are required to compile it yourself. It's very straightforward and it comes with a compiled HTML help file and samples. So far your profiles falls under IAT (Import Address Table) and EAT (Export Address Table).
I hope this non-snippet answer helps you a little bit in your approach to the solution, and if you get stuck come back again and ask. Best of luck!

Intercept BIG application execution after DLL injection

I must intercept execution in very big application in many places.
What programs I can use to do this? What techniques exists for this problems?
Manually reverse engineering and adding hooks is maybe not optimal solution for this problem, because application is very big and some part of application can be updated in some time, i think with some tools or good practices for this problem i can do this faster, anyone know how to do?
Anybody help me?
seeing as the tools part has been covered, here is something for the techniques.
Depending what it is you need to hook and whether or not there is protection invloved, there are a few methods:
Relative call/jmp patching in the virtualized binary: this is the simplest, but also a lot of work if you can't automatically find all references to a function, this probably won't work in this cause due to your criteria.
IAT/EAT hooking: this is use for imports(IAT) and exports(EAT), great if your targeting a known importted/exported set of API functions. a good example of this can be found here or here
Hot-Patching: Windows XP SP2 introduced something called "hot-patching" (used for realtime system function updates), where all its (the WinAPI) functions start with a 'mov edi,edi', allowing a relative jump to be patched into the free space created above every hot-patchable function(one can do it too). this is generally used for programs that checksum there IAT's or have other funny forms of protection, more info can be found here and here
Code-Caving: capturing execution flow by placing redirections in arbitrary code space. see here, here or here
VFT/COM Redirection: basically overwriting entries in a objects virtual function table, useful for OOP/COM based applications. see this
There are a lot of 3rd party libraries, most famous would probably be MS Detours, one can also look at APIHijack or a mini-hook engine.
Ofcourse nothing can substitute for the initial poking you'll need to do with a debugger like ollydbg, but knowing the method your gonna use can drastically short them amount time time spent poking around
Some details on what exactly you need to do (e.g. how do you determine where to break) would be nice. Depending on your situation, something like Pin might work.
I suggest using Deviare API Hook. It's the easiest way you can do what you need. It has some COM objects that you can use to hook an application from a different process. In your process you get full parameter information and you can use it in any programming language (I'm using C# and it works like a charm).
If you need to intercept registry API I suggest using Deviare to debug what you need to intercept but then you will have to make your own hooks, otherwise, you'll find performance issues.
You can do API Hooking if you are interested in intercepting method calls.
Or use some disassembler like softice or ollydbg or win32dasm.

How create custom user interface for Windows?

There are many applications for Windows these days that don't use native windows controls, don't have standard window frames and generally look different. What are some recommended techniques for creating such interfaces?
There are good reasons not to. Like that you will most likely not do a better job than Windows does. (Maybe it will look better (in your opinion), but will it behave?). Or that it's not what most users expect. Or that it will look like s**** on Windows 2011.
That said, it's not hard. You simply handle the WM_NC* events like WM_NCPAINT or WM_NCHITTEST. NC stands for Non Client (window area). And of course, there is a trick on Vista/Win7 (you have to announce it to the DWM).
From an implementation aspect, you could employ WPF (Windows Presentation Foundation) assuming you code for .NET :) It has pretty bunch of skinnable controls, that may look like native and may not.
From a design aspect, if your interface isn't going to follow documented standards (like the Windows UI guidelines), it has to be intuitive. I think the new generation of Windows applications will go through a growing phase in a manner similar to the early days of the Web. After a time, some standards or common themes will evolve.
Can you give us some sample applications? Some apps that don't use native windows controls use cross-platform GUI libraries, like Qt for C++ or Tkinker. These maintain the same look across different platforms.
I wouldn't really recommend making your user interface different deliberately. You don't stand to gain much. Your controls are almost always going to be buggier than native controls, and you are requiring the user to learn something new. Now, if you're controls add a large enough value to be worth the users' time it can be okay. But making them get used to different looking buttons is rarely worth it.
I`m not sure if this answer your question.
You can use third party skinning controls like from Infragistics, or SkinSoft for example.
But like Bubba said I`d recommend going for WPF.
Model-View-Controller! It's as valuable here as in web apps or anywhere else. Be sure to keep the part of your program that generates the custom UI separate from the part of your program that flashes the BIOS.
I know this question is 10 years old but none of the answers mention using an option in visual studio, dont know if it existed at the time.
Theres an option to remove the border of the window in visual studio (called borderStyle). Thats the easiest way to do it, using C#. After removing the border, all you have to do is create a new interface. If you're looking to do it in C++, i think you need to use DWM. I will let an example i found here.
https://github.com/melak47/BorderlessWindow
Another example (maybe without DWM? didnt test):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b98c4c06-9581-44d3-8e5a-4adb2316e653/win32-about-styles-how-can-i-do-a-borderless-window?forum=vclanguage
There is a lot of people disencouraging to do it in this thread but there's no reason to not do it, if you know what you're doing your application can look great.

Using MFC in Windows service?

I'm starting to develop a Windows service. I want to use some classes from my own, that has little dependencies to some MFC classes like CString, CSocket, CArchive, CMemFile and CObject. MSDN says you need to be very careful about which pieces of MFC you use in the Windows service, but don't specifies it and don't describes the problems that can occur.
My questions are:
what pieces of MFC can be used?
what problems can I expect, by using MFC?
which parts of Windows service are critical for MFC use?
is it advisable to use ATL instead of MFC for Windows service?
I'm not sure what they mean in teh MSDN article. As long as you don't use any of the GUI functionality you'll be fine - but that's a general design issue when developing services.
That being said, ATL has functionality specifically designed for building services IIRC so you may be better off using that.
To answer your questions (to the best of my knowledge):
1) the ones you specify are no problem.
2) I guess they mean synchronization issues with UI components. As long as you don't use any CWnd-derived classes you'll be fine.
3) don't understand the question.
4) See before, plus ATL is more lightweight so you'll have to distribute less, and provides build-in functionality that'll make it less of a pain to develop the service. See e.g. CAtlServiceModuleT. You'll still be able to mostly use your own classes, as CString is shared between MFC and ATL nowadays and ATL has classes for socket programming and memory file mapping itself. It doesn't have an equivalent for CArchive, and I'm not sure what functionality you use in CObject so I can't say whether there's an equivalent in ATL. So to conclude, I'd say 'yes' to this question.
(I know this answer is a bit late and this question was already answered but MFC in services is a sore spot for me...)
CSockets, far as I recall, require a Window. It makes an invisible one in the background. I found out this the hard way when I tried include some pre-exisiting MFC code into a windows service. Maybe this was only required if you accepted socket connection - I can't recall? But it did not work! (How exactly I wasted so much time doing this w/o realizing this limitation is a long story)
CObject? If you need the runtime class id stuff use RTTI (dynamic_cast, etc...)
CString, I like CString, I know it's shared with ATL now, not sure if you pull it in w/o MFC or ATL included... You could use std::string. Also, I recall someone created a derived std::string that provided the same methods as CString.
(EDIT: found the code - man!! that's a blast from the past...)
CArchive, CMemFile: do you really need these?
Anyway, as Roel said, ATL may be more helpful. I wouldn't use MFC in a server-side application (ever!) ATL? Maybe. If I needed COM, defiantly. No COM but for CAtlServiceModuleT, etc... maybe....
And another bad thing about MFC in services that I have just experienced while trying to turn a regular MFC-ATL app into a service: The use of AfxConnectionAdvise() is actually useless without a Window procedure. The threads in my service are just regular non message-pumping threads. I believe this is why I never get events fired from another COM server I have developed. That other COM server hangs on Fire_xxxEvent(), causing a big mess in the whole system.

How do I develop an addon for Safari?

I want some personally developed JavaScript code to execute whenever I load a page in Safari. Seems like addblock for Safari does this. Anyone know how to do this?
Safari is not extensible. There's no addon framework for it. But yet there's adblock and verious other addons available for it, although Apple's Webkit and Safari developers discourage users from using them, calling them 'binary hacks'. Seems though some of these addons use InputManager, which isn't documented at all anywhere, at least for not for how people are using it to load scripts in Safari. I guess I'm going to have to backwards engineer to see how addblock does it, but before I do, I thought I'd ask around here. Anyone know?
Input managers are a commonly (ab)used way of injecting arbitrary code into another application's runtime. Once you are there, you have to reverse-engineer enough of the application itself to figure out how to get the behavior you want; usually that involves method swizzling to replace parts of the application you are hacking. It's not documented because there's no API to document, but you can learn about the individual pieces (how to write an input manager in general, how method swizzling in Objective C works, how to use tools like class-dump) and then put it all together.
What you are describing sounds like Greasemonkey though, and there are least one or two hacks already out there to enable Greasemonkey-like behavior in Safari. I'd suggest seeing if one of them meets your needs first.

Resources