I have an application developed in VB 6.0. I don't have access to its code. This application also exposes its functionality through certain API provided in its dlls. Is there a way for me to check what methods of the API the consumers of this application's API are calling across anywhere the API is deployed. I want a C# program to just sit in that target environment and intercept the calls made to that API and report it back to my service via a service. I wont be modifying the API or the code calling the API. Is this possible in C# or would I need to go with C++?
Update
Lets say for sake of simplicity, that its a simple VB application developed in VB 6 called SimpleAPP, and it has a button that displays records in a grid. It does this by calling a component CMPA.dll with a public method GetRecords(string ID) which returns an Array of records. I have another few applications called CustomerApp.exe and AnotherCustomerApp.exe which also have a reference to CMPA.dll and they both calls this same method to get the records. Now, I want to develop a program called Interceptor.exe that will actually sit in the environment where CustomerApp and AnotherCustomerApp is deployed and will log internally which of these two applications called that CMPA dll's public method GetRecords and also log what parameter it sent in and what results were retrieved.
I had to google to find the library that was on the tip of my tongue.
That googling turned up some interesting articles: a new to me 1999 Microsoft Research article called “Intercepting and Instrumenting COM Applications” and an Microsoft Systems Journal article from january 1999 that I do remember, “Building a Lightweight COM Interception Framework”.
The library you want is probably Microsoft Detours. I have only used it from C++, not from C#, and I have only used it for intercepting calls to Windows API functions, not COM methods, so I can’t guarantee that it’s well suited. But it's not exactly rocket science to interface these two languages, if needed.
If Detours doesn’t turn out to fill your needs, then look at the articles cited. Quite possibly they resulted in some framework you can use. And otherwise they have the information you need to build your own. You might then also check out if ParkPlace ever made what you want. There was once great interest in “cross concern“ functionality, and ParcPlace did some of the most interesting research, as I recall.
Related
i work with c++ programming, I use an example for understanding main of my question.
Suppose, we want get current username in windows operation system, we can use follow code :
#include <windows.h>
#include <Lmcons.h>
char username[UNLEN+1];
DWORD username_len = UNLEN+1;
GetUserName(username, &username_len);
also, we can use wmi by follow the instruction explained on here and use Win32_ComputerSystem.UserName .
so, I hope you have fully understood, what's different between wmi and using api or any other way?
tank you for your response.
disadvantage :
Speed (mainly disadvantage)
if user turn off wmi service, wmi doesn't work.
advantage :
Wraps the native API
richer data, if you use wmi, you can get rich data
standardized, all the 'entities' are represented in a standardized way
These are the most important issues for using wmi.
Windows Management Instrumentation (WMI) is a set of specifications from Microsoft for consolidating the management of devices and applications in a network from Windows computing systems.
It is Microsoft implementation of Web-Based Enterprise Management.
WMI - Services are installed on Windows OS, but the service can be turned off. So if user disabled the service you wont get any information about the system. It is just for reporting purpose.
Whereas the APIs are ways thru which the Microsoft provides the access to the information to local Application and some how you can also manipulate the information provided.
WMI is query Based and its run very slow where as API are much faster to run .
Ex :- if you wanna check some System specification in your application before startup you should better use APIs . This will make you app Start faster.
WMI has advantage over api call WMI information is richer and easy to read where as to get that kind of same result we have to make several api calls .
The GetUserName API is merely a call to the function exported by the Advapi32.dll wich belongs to base kernel functions.
Using Win32_ComputerSystem class you are going to query Windows Management Instrumentation which is a complex and comprehensive infrastructure services which deals with most of the administrative tasks on Windows.
Posting a query to WMI involves much more resources and execution time so, if your goal is simply getting the user name, I suggest you to rely on the GetUserName API.
I am trying to learn hooking and want to hook only an .exe's send/recv function.
I'm building the project as a .dll and then injecting it to the .exe
Edit: solved
There are 3 ways of hooking an API call as far as I know:
Inject a DLL in the application that will rewrite the Import Address Table containing the address of the API call, so that the application calls your function instead;
Write a dummy DLL with same name of the DLL with the API call you want to hook and place it in the applications's root directory, so it will load your APIs instead of the system's;
Detour the API call by rewriting it's code with a JMP yourfunc or something with similar effect.
Method 1 is pretty popular one, it's even described in the Wikipedia page about Hooking and in various examples if you Google it, like this one, or this one.
Method 2 is a bit tricky, you have to build a DLL with the same name and exports as the one you're mimicking, and bypass all the functions you're not interested in hooking and write custom code for the one you are. I find this method very clean because you don't have to modify memory, you don't have to explicitly inject this DLL using an external program, Windows just does it for you, and with a plus, it generally fly under the radar of anti-debug and anti-hack detection. Here is an example of how to do that (32-bit).
Method 3 is Microsoft's favorite. It has a particularly good advantage: You can hook any and every function, method, or virtual calls. It doesn't depend on the function being called externally to hook it, so it's very popular to hook DirectX methods for instance. This is the method used by FRAPS, Discord Overlay, Overwolf Overlay and pretty much every other software that either places an overlay in games or records gameplay. You don't need to use Microsoft Detours specifically, there's the generic alternative aswell.
I am developing an application on Windows 10 that interacts with custom device drivers, the NTFS filesystem and DirectX 12. The app is a Windows Universal App written in C++, WRL, XAML and DirectX. For DirectX I have chosen a SwapChainPanel control and the DirectX portion of the app works great. The app is Sideloaded so I have a bit more freedom than an app that needs to go through the store
Unfortunately the Windows Universal Apps have a number of restrictions with regards to API calls. WinRt APIs are favored.
Here are a list of WinRt APIs to call to replace Win32 APIs:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
In addition Windows Universal Apps can call Win32 APIs that are partitioned to the application (however not the ones partitioned to the desktop) as indicated in the documentation of each function and in the header file. Here is a link:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
In addition the Winsock APIs are now allowed from Windows Universal Apps
However I am still left without my favorite (and necessary APIs)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
In particular I need to read and write files to all locations without user interaction (and not to the locations restrict by the Windows Universal App Sandbox). In addition I need to send IOCTLs to my multiple device drivers.
I could abandon Windows Universal Apps and go with WPF. However I have a touch intensive application and I need touch to work really well. In addition I have to wonder about the lack of fixes and commitment to WPF on the behalf of Microsoft. I have considered other UI frameworks but none have been as promising as a Windows Universal App.
Microsoft has allowed two paths in Windows 10 for Universal Apps that will allow calling all Win32 functions (For side loaded apps).
Brokered Windows Runtime Component
and IPC though TCPIP
I have written a brokered windows runtime component and it works well. However the solution requires a C# app to be in the mix and I do not need/want that as I need fast load times of the app and do not want to pull the CLR in.
The next option is IPC through TCPIP. I would use Fast TCP Loopback as explained in the blog post: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path. I would link to it but I am at my (very generous) two link limit for a first post.
I have a couple of questions:
1) If I go this route should I place the IPC between the XAML controls/buttons and the rest of the App? This would allow the rest of the app to be strictly Win32. Or should I just place the IPC between the app and calls to the specific functions I need that fall outside of the those allowed by Win32.
2) I have looked for a library or paper that has code and/or ideas for implementing IPC with TCPIP. However so far the papers that talk about IPC with TCPIP seem to simply describe winsock programming which is something I already know how to do. I would enjoy coding up IPC but would prefer a solution that has been tested. This needs to work flawlessly and I would rather have code with some time on it. Has anyone used or heard of code and or a design for IPC over TCPIP that is available to share?
I'm currently attempting to developing a small application / dll that will read a remote directshow filter graph and glean information from it for display in a "now playing" style plugin or script. After a few days of reading and subsequent testing, I realized that after getting the filter graph address from the ROT I was failing to convert it from the IUnknown interface pointer to IFilterGraph until I had registered "proppage.dll" which came with Windows SDK.
So what I am asking is, is there no other way to glean any information from a remote filter graph without having to register proppage.dll?
You can't call a COM interface from another address space unless you marshall the interface pointers and parameters/return values to and from the other process. For COM, you need to register a marshalling object for each interface that you want to be able to use cross-process. The standard implementation for that is in proppage.dll.
I don't think there is a simple way to access the interface without providing marshalling. If you don't want to use proppage.dll, you can build marshalling code from the IDL files supplied with the SDK and compile that into your own app.
G
I wrote a device controller (rs232) and it is being used successfully, however users want to view data and control the device (or perhaps communicate through my program) from Excel. I dismissed DDE as an option and found that RTD (IRtdServer) is probably a good start (though no way to send data back to the "server" from the real time data client).
I found these resources for the RTD part:
http://support.microsoft.com/?id=327215
and
http://support.microsoft.com/?id=327215
This is a multi-threaded app and I had already added the ability to have multiple listeners on the com port so that I could update multiple clients. I will add the COM interface to the EXE.
But what I need after that is some way of controlling my app/proxying commands to the device through my app from Excel.
What would be the best way to do that?
Perhaps another COM interface and calling it from VBA or something? I am not familiar with using scripting from Excel, so perhaps someone can provice sample code or links that show both the code for a COM object and the accompanying VB(A?) code?
Keep in mind that this is an unmanaged C++ application and it cannot be converted to managed or C# right now. Alternatives using C# are welcome as well, but that is a long-term rewrite.
Thanks
EDIT
I have an alternative to adding COM support into the existing EXE. I think it is more flexible to add a two-way communications (cross platform - maybe boost or corba or just straight IP based with my own message protocol)
A COM server (or two) can wrap that communications channel - whatever it is. This doesn;t really affect my question at all - I still would like to know the options for controlling an external EXE from Excel.
EDIT
Not having to roll out .NET to customers is also an big plus. many of these devices are on PCs that are pretty old and have perhaps NT or XP on them and I don't relish increasing my setup/install package from 700KB to the ridiculous .NET install size...
Option #1:
Create a small COM server - make sure its interfaces are suitable for scripting with the built Visual Basic engine in Excel. (e.g. use simple types and BSTRS).
Write Excel VB Macros to (1) add your own tool bar to excel and (2) call your COM server.
You can also add buttons and other UI elements to sheets and hook them them up to VB macros.
Option #2:
I realize that you do not want to use C# - but automating office, and talking to COM objects is really, really easy in C# with Visual Studio Tools for Office (VSTO). You shoul really look into this option - If done correctly, it shouldn't mean re-writing any of your existing code. Just use C# and VSTO as a bridge between Excel and your RTD server. As with VB, its straight froward to connect UI elements in Excel to C# and then to your RTD server.
Calling a COM object from VBA is straightforward. This SO Question and my answer give an example of how to create a COM object. Calling exposed methods is as you would expect:
object.ExposedMethod(optional params...);