What is the best practice of logging DLL activity and internal parameter values.
I wrote a DLL that is used by a few applications I wrote. Lately, some users were complaining about problems that I suspect are related to this DLL but I cannot reproduce on my dev machine.
I'd like send them an equivalent DLL file that will log its activity, such as function calls, function return values and some internal parameters.
I don't think there should be a problem for a DLL to create a log file and write to it. Is there a common practice related to this issue. Is there a standard place to write the data to?
I am currently facing a similar issue of how to provide logging from a DLL. The way I went about it is to provide callback function setters and a callback type header file as part of the API. That way, the caller of the dll can create their own type of logging (boost, log4cpp, etc) and the dll will call the callback function in the exe that the user can do whatever they want with the data. In my case, I forward the log msgs to a boost logger that is instantiated in the exe. It's a little hacky looking but seems to work pretty well since the exe controls when and how to log everything and the user can format the data any way they choose.
You could provide an interface on your DLL which allows the user to provide a log file path/handle as the logging sink.
If you auto-generate the log file you'll probably want the file name to contain the process name and the process id (to disambiguate multiple simultaneous runs).
on unix machines the usual place is /var/log
on windows the standard way is to log to the event log (a separate subsystem of the OS).
I would suggest using the active user's TEMP directory if you want to log to file...
...or you could be clever and get the DLL to log to your own machines via TCP.
Related
My app needs to write and maintain a log file and its not running in admin mode. My question is what path could my app write to in such a situation. How could I obtain that path ?
There are two good options:
Use the Windows Event Log. You can easily create your own log for your application (if you expect to generate a lot of messages), or you can just add the messages to the standard logs (if you expect to generate only a few, occasional messages).
Since this is a built-in feature, any technical person is going to know about it and be able to locate your log files easily. It's also very interoperable with centralized management systems.
Write to a text file saved in the Application Data directory. This is where applications are supposed to store non-user data files, since, as you mentioned, the application directory is not something you can assume write privileges to.
For a log file about stuff that is specific to a particular computer, I'd say that this is local (non-roaming) application data, so you want the Local App Data folder. I'm sure that there is a Qt wrapper for this, but in Win32, you would call the SHGetKnownFolderPath function, specifying the KNOWNFOLDERID value FOLDERID_LocalAppData.
Remember that this function allocates memory to store the returned string—you must free it with a call to CoTaskMemFree when you are finished.
Sample code:
// Retrieve the path to the local App Data folder.
wchar_t* pszPath = 0;
SHGetKnownFolderPath(FOLDERID_LocalAppData, 0, NULL, &pszPath);
// Make a copy of that path.
std::wstring path(pszPath);
// Free the memory now, so you don't forget!
CoTaskMemFree(static_cast<void*>(pszPath));
Refer to the SHGetKnownFolderPath API, probably using the FOLDERID_LocalAppData option.
I need to hook copyfile in order to stop the process whenever a malicious file is being copied. I saw a question asked by Cat Man Do
Hook into the Windows File Copy API from C#
and he mentioned that there is a solution for this problem in c++. I am using embarcadero c++ builder(non-MFC). Is this solution applicable for c++ builder and if it is can anybody post the link or give me a hint on how to hook copyfile in c++?
You're not being specific about what you mean by "stop the process" - whether there is a specific process you are interested in, or whether you want to block all file copies throughout the entire system. If you want to block all file copies throughout the system, then what you're looking for is a file system filter driver. This is extremely advanced, since you will be writing a kernel-mode driver. Not for the faint of heart. Note also that you may end up being flagged as malware yourself, since malware will try to hook the file system in order to hide themselves.
I recommend using Deviare API hook to do it. You can use its COM objects to intercept CopyFile and CopyFileEx APIs and prevent the call returning ACCESS DENIED in the last error.
I need to make a file not appear to another program. For instance, when another program gets the list of files in a folder, I want one particular one not to show up. I am injecting a DLL from which my code will run into the process from which I want to hide the DLL file on the filesystem. I am using Microsoft Visual C++ 2010 and Windows 7.
Yes, as you've mentioned you need to intercept the file/folder enumeration APIs and filter out the specific file/folder from the enumeration result in order to "hide" that file/folder. This can be done either at user mode or kernel mode.
User mode: User mode hooking involves DLL injection. There are many places where you can hook:
IAT hooking of executables: Find out the entry FindXxx in import address table of the target process and overwrite it with the address of trampoline function present in injected DLL.
EAT hooking of DLLs loaded by executables: Find out the entry of FindXxx APIs in export address table of loaded DLL (kernel32.dll in this case) and overwrite it with the address of trampoline function present in injected DLL.
Inline hooking: Overwriting first few instructions of an API code in a loaded DLL with a JMP to your trampoline function.
Generally, user mode tend to become "ugly" (difficult to manage) as you need inject your DLL into all of the running processes if you want a system-wide hook (or at least into Explorer.exe or your target application). Many applications, like security software, have protection mechanisms to detect and deny DLL injection.
A cleaner way to implement user mode hooking is to hook APIs in NTDLL.dll (using either EAT or inline hook). All other APIs (like FindFirstFile/FindNextFile) end up calling an equivalent NtXxx APIs (like NtQueryDirectoryFile) provided by NTDLL.dll. The NtXxx API is the point where control jumps to kernel mode by executing INT 2E/SYSENTER.
Kernel mode: This involves writing a driver. Again, in kernel mode there are many places where you can install hook:
SSDT hook: Install an SSDT hook for the required ZwXxx API (ZwQueryDirectoryFile in this case) by overwriting the corresponding SSDT index with the address of trampoline function in your driver.
Kernel inline hook: Overwrite the first few instructions of NT kernel API exported by kernel (NtQueryDirectoryFile in this case) with a JMP to point to trampoline function in your driver.
File system filter driver: This is a cleaner approach and no hooks are involved. Install a file system filter driver and intercept read/write/enumerate IOCTLs and filter out the results to hide/lock a specific file/folder.
Kernel mode hook tend to be cleaner as they generally installed at one "centralized place". However, you should be very careful as a small mistake/mishandling in driver code can end up with a BSOD.
PS: There are many hooking library/frameworks available to ease the job of writing code. Some popular ones are:
http://www.madshi.net/madCodeHookDescription.htm
http://easyhook.codeplex.com/
PPS: Hiding files/folders using such techniques without user's consent might be a questionable action and can become problematic (Remember Sony DRM protection software issue? ;) ). This is what rootkits do! There are many user mode and kernel mode rootkits that use the techniques mentioned above to hide files/folders. There are various anti-rootkit software available to detect and restore all sorts of hooking described above. Many anti-virus software raise a flag when they detect such rootkit like behavior (like API hooking, hidden files, SSDT hooks etc.)
Few resources:
http://www.codeproject.com/KB/threads/APIHooking.aspx
http://www.codeproject.com/KB/DLL/funapihook.aspx
http://www.codeproject.com/KB/system/api_spying_hack.aspx
http://www.codeproject.com/KB/system/hide-driver.aspx
http://www.uc-forum.com/forum/c-and-c/59147-writing-drivers-perform-kernel-level-ssdt-hooking.html
http://www.security.org.sg/code/apihookcheck.html
Easiest way to do that would be using Microsoft Detours to override the functions you need. It can also be used to inject the DLL, but you already have that covered. If there's a specific function used by the other process that is known to you, hook on that. If not, you'll need to hook on the building blocks of all functions used to list files or open them. Hooking just CreateFile/FindFirst/FindFirstFile/etc would be enough as they just call an internal function. For example, if you hook CreateFile which actually maps to CreateFileA, the process will still be able to access the file using CreateFileW. So you want to hook NtCreateFile and friends. But I guess you know which process you're messing with, so you know exactly which functions to mess with too.
I'm trying to make a small program that could intercept the open process of a file.
The purpose is when an user double-click on a file in a given folder, windows would inform to the software, then it process that petition and return windows the data of the file.
Maybe there would be another solution like monitoring Open messages and force Windows to wait while the program prepare the contents of the file.
One application of this concept, could be to manage desencryption of a file in a transparent way to the user.
In this context, the encrypted file would be on the disk and when the user open it ( with double-click on it or with some application such as notepad ), the background process would intercept that open event, desencrypt the file and give the contents of that file to the asking application.
It's a little bit strange concept, it could be like "Man In The Middle" network concept, but with files instead of network packets.
Thanks for reading.
The best way to do it to cover all cases of opening from any program would be via a file system filter driver. This may be too complex for your needs though.
You can use the trick that Process Explorer uses to replace itself with task manager. Basically create a key like this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe
Where you replace 'taskmgr.exe' with the name of the process to intercept. Then add a string value called 'Debugger' that has the path to your executable. E.g:
Debugger -> "C:\windows\system32\notepad.exe"
Every a process is run that matches the image name your process will actually be called as a debugger for that process with the path to the actual process as an argument.
You could use code injection and API redirection. You'd start your target process and then inject a DLL which hooks the windows API functions that you want to intercept. You then get called when the target process thinks it's calling OpenFile() or whatever and you can do what you like before passing the call on to the real API.
Google for "IAT hooking".
Windows has an option to encrypt files on the disk (file->properties->advanced->encrypt) and this option is completely transparent to the applications.
Maybe to encrypt decrypt file portions of a disk you should consider softwares like criptainer?
There is this software as well http://www.truecrypt.org/downloads (free and open source) but I haven't tried it.
Developing a custom solution sounds very difficult.
I've encountered the following problem pattern frequently over the years:
I'm writing complex code for a package comprised of a standalone application and also a library version of the core that people can use from inside other apps.
Both our own app and presumably ones that users create with the core library are likely to be run both in batch mode (off-line, scripted, remote, and/or from command line), as well as interactively.
The library/app takes complex and large runtime input and there may be a variety of error-like outputs including severe error messages, input syntax warnings, status messages, and run statistics. Note that these are all incidental outputs, not the primary purpose of the application which would be displayed or saved elsewhere and using different methods.
Some of these (probably only the very severe ones) might require a dialog box if run interactively; but it needs to log without stalling for user input if run in batch mode; and if run as a library the client program obviously wants to intercept and/or examine the errors as they occur.
It all needs to be cross-platform: Linux, Windows, OSX. And we want the solution to not be weird on any platform. For example, output to stderr is fine for Linux, but won't work on Windows when linked to a GUI app.
Client programs of the library may create multiple instances of the main class, and it would be nice if the client app could distinguish a separate error stream with each instance.
Let's assume everybody agrees it's good enough for the library methods to log errors via a simple call (error code and/or severity, then printf-like arguments giving an error message). The contentious part is how this is recorded or retrieved by the client app.
I've done this many times over the years, and am never fully satisfied with the solution. Furthermore, it's the kind of subproblem that's actually not very important to users (they want to see the error log if something goes wrong, but they don't really care about our technique for implementing it), but the topic gets the programmers fired up and they invariably waste inordinate time on this detail and are never quite happy.
Anybody have any wisdom for how to integrate this functionality into a C++ API, or is there an accepted paradigm or a good open source solution (not GPL, please, I'd like a solution I can use in commercial closed apps as well as OSS projects)?
We use Apache's Log4cxx for logging which isn't perfect, but provides a lot of infrastructure and a consistent approach across projects. I believe it is cross-platform, though we only use it on Windows.
It provides for run time configuration via an ini file which allows you to control how the log file is output, and you could write your own appenders if you want specific behaviour (e.g. an error dialog under the UI).
If clients of your library also adopt it then it would integrate their logging output into the same log file(s).
Differentiation between instances of the main class could be supported using the nested diagnostic context (NDC) feature.
Log4Cxx should work for you. You need to implement a provider that allows the library user to catch the log output in callbacks. The library would export a function to install the callbacks. That function should, behind the scenes, reconfigure log4cxxx to get rid of all appenders and set up the "custom" appender.
Of course, the library user has an option to not install the callbacks and use log4cxx as is.