I'm working on on-line encryption driver for MacOS. And one of the issues I encountered recently is that I have to control(hook/intercept) some of the regular system functions (on application/user level) like : mmap, open, close ... on system-wide basis, so that I could arbitrary turn on or off that control.
I looked at some of the examples and solutions available, - probably not all of them, - but they all work for that very application that does the hooking, while I need the sort hook that could intercept system calls made from any other application. For example, what do I do to hook and control the call to, say, 'mmap' in /usr/lib/system/libsystem_kernel.dylib, regardless of what application calls that 'mmap'.
I tried rd_route, substitue ... but they seem to work for the application itself and other applications bypass the hook.
Related
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 have created a set of multi-platform C++ components to load and manage various types of digitally signed shared libraries. This handles all aspects of loading and initialziation including mapping them into the calling process, applying branch fix-ups, binding any imports and calling the initialization entry point. The components cannot use LoadLibrary() as it is platform specific and not all of the shared libraries are in PE format.
One of the few remaining issues I am faced with is providing appropriate debugger support for targeted platforms and development environments. In MS Windows environments this includes getting the debuggers to load symbol information generated by the compiler and linker (or converted from other source). Because the loading and initialization of the libraries occurs outside of the kernel, the debugger never receives LOAD_DLL_DEBUG_EVENT and UNLOAD_DLL_DEBUG_EVENT events. This leads to the following questions:
Is there an API or system call that allows events such as LOAD_DLL_DEBUG_EVENT to be sent directly to the debugger?
Is there a documented way to communicate directly with the program or session debug managers or with the machine debug manager service?
Is there an API or system call available to notify the kernel and subsequently the debugger that a DLL has been loaded? Since PE files are one of the primary supported formats this is the most desirable option. It also has the potential benefit of allowing the library to appear in the module list of the process.
Does the WinDBG SDK apply to debugging on Windows as a whole and can WinDBG extensions be used to instruct the debugger to load the symbol information?
I have search extensively for information on the above mentioned topics but have come up short. I have located a bit of information about the data structures used by the Windows debugger but nothing relevant to my specific situation.
I am open to API/system calls and approaches that are documented or undocumented and those requiring elevated privileges to function.
I don't think that there is a way to directly send the kind of events that you want (like LOAD_DLL_DEBUG_EVENT) to a process, at least not easily.
Why don't you simply wrap your libraries inside normal DLLs in Windows? Maybe you embed your custom module loading mechanism inside each "proxy" DLL, in this way you would not need to replicate so much functionality that the OS already provides for you.
If I understood the problem, you may see:
Writing a basic Windows Debuggers
Writing Windows Debugger (Detailed)
I'm trying to understand event hooks in C++. I know what an event is, I've used them a lot in Java, C# and Javascript.
What I'm having trouble with is finding the documentation, and tutorials on stuff like global hooks, dll injection, global hooks without a DLL.
Lets say that I wanted to iterate through the browser tabis in FireFox .. would I need to hope that FireFox has an API for C++? Or lets say I wanted to do something when a user opens a new tab would I need to use a hook that FireFox would provide in their API?
The above is just an example so people know what I'm trying to learn/understand. Am I thinking on the right ines?
I seen a post on a forum and for the past 2 hours I've took an interest. I always say that a tricky challange, or a new challange, makes a stronger programmer.
Any resources, or any help, would be very much appreciated.
C++ itself does not have events or hooks, but a lot of C++ libraries and frameworks implement them. For an example of generic events library, see Boost.Signals.
Some of the implementations allow their events to be seen by other applications, but the API is application-specific (e.g. for Firefox, see XPCOM).
Windows has a mechanizm of hooks that allows to monitor various events in its windowing system. However, it is an OS feature, not related to C++. As it's a system mechanizm, all Windows applications are affected even if they don't do anything for it. The documentation for Windows hooks can be found here. Also, since you mentioned "global hooks without a DLL", see SetWinEventHook, which is a higher-level API than Windows hooks linked above and can be used with hook functions both implemented in DLLs or EXEs.
Look up MSDN for SetWindowsHookEx. It should be your entrance in Windows hooks. If you ar etargetting a parituclar window for mthe system then a less intrusive option is SetWindowLongPtr. For the first API you are going to need some Dll injection - which gets automatically for you by the system. Just follow these steps:
Create a Dll that exports a HOOKPROC function (actual type dependent upon the hook tpe - read in the docs)
Load that Dll in your application and retrieve a pointer to the HOOKPROC function. LoadLibrary / GetProcAddress APIs may be used for this.
From your application, make a call to SetWindowsHookEx feeding in the appropriate parameters - this will inject the dll in the target process. So, the dll is now loaded into both your app's process and in the target process. So you will need a mechanism to IPC between the two processes probably. Lots of ways here - sockets, pipes, shared segment in DLL, filesystem, windows messages, COM servers + events, etc etc.
The former API, while less powerful, does not require DLL injection.
Choose wisely & good luck!
I dont think firefox would be having a C++ aPI to find the open tabs....
If you want to find out open tabs or whenever a new tab is open , you can basically hook the firefox window and get all events happening on that window to your hook procedure.
If you open spy++ in VC++ and track firefox window , you can see a new MozillaContentWindowClass gets created every time whenever a new tab is opened. So you can basically iterate through window handles and get information about open tabs.
You can use SetWindowLongPtr to set the subclass procedure for that window.
I was having a discussion with a colleague about whether or not the following is possible:
Install an MFC application from a USB drive in Windows XP (this installation would be initiated manually by a user with sufficient privileges to install software).
After rebooting, this application should start instead of the default Windows XP shell (explorer.exe).
Does anyone know how I might accomplish this?
You won't be able to run an MFC application before windows starts up because by definition MFC runs off of windows DLLs that are not loaded until windows itself is. Not to mention that Windows is what is responsible for loading a PE in the first place, so you won't even be able to load a compiled EXE or DLL without a custom bootstrapper.
In order to do what you want to do you have a few options. There are (easy) ways for windows to be set to load an application on startup. If that is what you want, then this is entirely possible.
However, if you wish to execute code before and while windows is starting up, then you must first overwrite the bootstrapper (with something like GRUB), execute your code (again, you will not have access to any standard library - you will have to operate directly on the buffers made available to you by the CPU if you wish to do any sort of I/O), then start up windows by launching its bootstrapper. I have no idea how to do this; but that is the general overview of what must happen.
You mentioned DLL injection, which is another possibility. I am not familiar with what DLLs, and in what order, are loaded during windows startup. That will be an exercise for you. What you will have to take into consideration, is that the higher level you want to exist in (i.e. what libraries are available for you to do File/Console I/O) the higher up you need to execute your code in the windows startup process.
My suggestion to you is simply write a program that executes as a service that is started up during windows initialization. Its easy to do, and you will have the entire HAL loaded and ready to actually perform tasks - rather then you having to write device-specific drivers in order to manipulate hardware before window's loads the HAL.
Modify HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit registry value with full path to your application. This key specifies what program should be launched right after a user logs into Windows. The default program for this key is C:\windows\system32\userinit.exe. Userinit.exe is a program that restores your profile, fonts, colors, etc for your username. It is possible to add further programs that will launch from this key by separating the programs with a comma
In Windows when you create a window, you must define a (c++)
LRESULT CALLBACK message_proc(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam);
to handle all the messages sent from the OS to the window, like keypresses and such.
Im looking to do some reading on how the same system works in Linux. Maybe it is because I fall a bit short on the terminology but I fail to find anything on this through google (although Im sure there must be plenty!).
Is it still just one single C function that handles all the communication?
Does the function definition differ on different WMs (Gnome, KDE) or is it handled on a lower level in the OS?
Edit: Ive looked into tools like QT and WxWidgets, but those frameworks seems to be geared more towards developing GUI extensive applications. Im rather looking for a way to create a basic window (restrict resize, borders/decorations) for my OGL graphics and retrieve input on more than one platform. And according to my initial research, this kind of function is the only way to retrieve that input.
What would be the best route? Reading up, learning and then use QT or WxWidgets? Or learning how the systems work and implement those few basic features I want myself?
Well at the very basic level you have the X Window protocol http://en.wikipedia.org/wiki/X_Window_System_core_protocol, which we can be pretty complex to handle if you want to do any application. Next on the stack there's Xlib http://en.wikipedia.org/wiki/Xlib which is a "convenient" wrapper around the X protocol, but still is complex for "real life" applications. It's on top of Xlib that most other frameworks are built, trying to simplify application development. The most know are: Xt, Gtk, Qt, etc.
Like in window you have a "event loop", and if you want you can implement on top of it a GetMessage/DispachMessage metaphor to mimic the windows behavior. That way you may have a WNDPROC, but natively X doesn't provide such thing.
Before reinventing the wheel is preferable to take a look at similar applications, what they are using.
If you need something simple you can try SDL http://www.libsdl.org/, which is a cross platform library to aimed to develop games/simple applications. Another alternative is Allegro game library http://www.talula.demon.co.uk/allegro/.
In principle it is absolutely the same. However, it has nothing to do with communication with the OS (nor does it on win32, using user32.dll is entirely optional)
A GUI application has an event loop somewhere, which processes messages from a queue at some level.
There are a lot of libraries typically used to "hide" this behaviour - you can use them (and indeed, you should). If anything, the Xlib event system is even more perverse than Win32's user32.dll one, and is less widely understood, therefore fewer people use it directly.
In Linux or in Windows, applications can use the low-level GUI, or can use a library. Most use a library. Applications can also choose to do neither and operate without a GUI (server applications typically do this). Applications can create multiple threads, one of which sits in an event loop, and others work differently. This is a popular approach too.
Most GUI applications use a higher level library for their GUI
Non-interactive applications, e.g. server applications, don't use the GUI at all and don't use the libraries (e.g. XLib, user32.dll)
Applications which don't lend themselves to an "Event loop" (e.g. Games) typically use a separate thread to process their event loop.
These things are largely true on Win32 and Linux.
It's totally and utterly different. That window procedure is 100% specific to the Windows OS. For linux, it will depend on the window manager (gnome, kde - as you've already mentioned). If you wish to do cross-platform development, you might want to look at things like QT.
You may wish to take a look at the following URLs:
http://www.qtsoftware.com/products/appdev
http://en.wikipedia.org/wiki/Qt_toolkit
As stated by xhantt, what transport the equivalent messages you are looking for is the X Window System. Which, indeed, can be a bit complex.
With XLib you will need to handle the events registering and dequeuing in your main loop. See the XLib manual for a complete description on how to proceed. But don't forget that you will only catch window and inputs events this way. Not every OS messages.
You can also look for XCB which is a newer, and probably easier, library.
If you build your application on top of those two library, it will run smoothly under (almost, we can never be too sure) every WM. And you won't require any dependency that most linux user don't already have on their installation. If you go with Qt, GTK, etc... It will be easier and work under any WM, but they may not have library installed.