I'm developing an Internet Explorer ActiveX plugin using Qt, and trying to make the installer ensure the plugin is not running before continuing. A standard approach to this is to create a named mutex in the application and try to open it in the installer.
This works fine when built as a standalone .exe, but when the plugin DLL is loaded by either idc.exe (to register the server or handle the type library) or IE itself (after adding a test against argv[0] to skip CreateMutex for the idc runs), the CreateMutex call crashes.
Here's how I'm calling it:
CreateMutex((LPSECURITY_ATTRIBUTES)MUTEX_ALL_ACCESS, FALSE, "mutex_name_here");
Is there a reason this should fail when run within the context of an ActiveX server, but work correctly when running standalone? Is there something else I'm missing here?
The first parameter to CreateMutex() is a pointer to a SECURITY_ATTRIBUTES structure (which contains a pointer to a security descriptor); it's not a set of requested access rights bits, which is what you're passing in. I'm not sure why that would work any better in a standalone application.
You probably want to pass in NULL for the first parameters so the mutex gets created with a default security descriptor.
The Desired Access bits would get passed to OpenMutex().
Related
I'm working on a way to hook any API call to perform some verification on the function. (I'm creating a SandBox)
The first way that I think about, is with register key, and implement our own dll into MicrosoftNT to be able to redirect any defined syscall. https://www.apriorit.com/dev-blog/160-apihooks .
Problem? only work on 32 bit, and if the binarie is loading User32.dll, so it's abig issue.
The second way is to inject a dll into a process? Simple but impossible, most program is defended from those injection, so it's not possible.
The last way that I think was to modify the SSDT to change the function address by mine and redirect to the original by creating a driver. Or by InlineHook and just modify the first byte of each address that I want.
The Problem, only working on 32 bit, because windows add a PatchGuard on the Kernel, so we can't do that.
We can delete de PatchGuard but, anticheat will notice the technique.
For the Sandbox I think it won't be a problem to delete a PatchGuard.
The main problem is for real time analysis, I have no more idea how I can do to hook every API call that I want, on any windows OS. I mean on 32 and 62 bit.
I'm a beginner in this domain I started this week so I'm open to any suggestion.
You say you want to hook every API call for a sandbox but then reference the SSDT? Those are two very different things. Do you want to hook VirtualQuery(Ex) or do you want to hook NtQueryVirtualMemory? From kernel or user mode? Or maybe you're referring to all loaded module exports as well as kernel system services?
WinApi
Iterate all loaded modules as well as installing an event to hook all future modules loaded. For each one you will iterate all exports and apply a hook of your preference which all jump to some handler. This handler should be raw assembly that preserves the CPU state, calls some method that does the logging and filtering, restores CPU state, before finally jumping to the original.
Syscalls
Disable Patchguard and apply hooks to every method in the service table similar to the WinApi method described above. This is definitely not suitable for production for obvious reasons.
Use an instrumentation callback which uses ZwSetInformationProcess to redirect most syscalls to an arbitrary assembly block. You can extract the syscall id here as well as parameters. Universal support is an issue though as it wasn't introduced until W7 iirc and you have a lot of limitations prior to W10.
Map a wrapper module that has a hook for every syscall into each newly loaded process from kernel. These hooks will apply to ntdll and simply invoke an NtDeviceIoControlFile call with the syscall id and arguments, forwarding it to your kernel driver for processing. This is commonly employed by antivirus software to monitor user mode system calls without disrupting Patchguard.
The most approved method would probably be callbacks. You can register process and thread callbacks in kernel, stripping handle access at your leisure. This will give you full control over process and thread access from external processes, and you can add a file minfilter to similarly restrict access to the file system.
I have a C# wrapper over C library.
In C lib I have function which takes callback as input.
In C# I have exposed callback like delegate.
Everything works fine in normal mode but when I try to call same function in remoting mode it gives exception like
Could not load file or assembly.
My scenario for remoting is like
1)SharedLib: I have a c# shared lib which has functions which are wrapper over C functions.
All functions are defined in this lib.
2)Server Console Application: Role of server is to get session from Shredlib and open a port so that client ask server for Session
3)Client Console application: Client listen to port opened by server and get session object from server.It defines a functions having same signature as delegate in sharedlib
On session object client calls method from sharedLib which take callback as input.
Client pass address of method having same signature like delegate to method from sharedLib which expects callback as input.
After this I got exception like "Could not load file or assembly."
If I pass null to parameter which take callback as input then everything works fine in remoting mode also.
So can anybody help in using callback in remoting mode.
Three suggestions:
1) Are the different AppDomains running at the same trust level? The second domain may not have permissions to load assemblies if the trust level is lower.
2) The remote application doesn't have all of the dependencies required available to it in the directories it loads assemblies from.
3) Are both applications running under the same version of .NET? If one is .NET 4.5 and one is .NET 3.5 and there's a .NET 4.0 assembly there, then the second process would not be able to run it.
You could try turning on Fusion assembly binding logging to see if there's a more detailed reason why the load fails.
I am developing an windows application.
what I want is to prevent this application running multiple in single OS.
(e.g. we can run multiple instance of notepad.exe, calc.exe at the same time... but I don't want this)
what is the most effective way to implement this?(preventing multiple instance of process running at same time)
I'd rather not use methods like checking process names or sharing some global file as a signal... since it is too easy to circumvent
thank you in advance
This is typically done with mutexs. When your process launches you call CreateMutex and check the return value. If it succeeded then this is the first launch, otherwise there is another instance of your process alive. Your mutex should be in the Global\ namespace. Also make sure to ReleaseMutex when your program finishes running.
What framework are you using? I'm assuming it's .Net? Here's a post from an msdn foum on the same thing.
http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/3e139912-45ea-432e-b9e0-e03640c07c9f/
You mentioned you don't want to check current process names or use a global file.
Lock the current executable
.NET example code:
System.IO.File.Open(
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName,
System.IO.FileMode.Open,
System.IO.FileAccess.Read,
System.IO.FileShare.None);
The FileShare.None keeps any other process (like Windows Explorer) from executing the file until the app closes or the file handle (returned object) is explicitly closed.
Global Mutex
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682411%28v=vs.85%29.aspx
If the mutex is a named mutex and the object existed before this
function call, the return value is a handle to the existing object,
GetLastError returns ERROR_ALREADY_EXISTS, bInitialOwner is ignored,
and the calling thread is not granted ownership. However, if the
caller has limited access rights, the function will fail with
ERROR_ACCESS_DENIED and the caller should use the OpenMutex function.
Global mutex is the easiest way. To clarify another answer you don't just check the return value you check the GetLastError value as well.
We have a setup here where every process is signed. We have a process with SYSTEM privilege that exposes COM interfaces. We do not want processes other than the ones signed by us to use the COM interfaces. Is there any way to accomplish this? We are also exploring other Windows IPC mechanisms that could allow this. Feel free to suggest other IPC Mechanisms that makes this possible.
Currently we are sending the pid, along with the request but that can be easily spoofed. Any suggestions?
Register a custom proxy/stub or inproc handler and have the proxy or handler incorporate code which checks the signature on the binary.
Make all access go via an inproc COM object which performs the validation and undergoes a challenge/response process with the server. Of course that can be spoofed too if they are handy with a debugger.
Just give up on it. Even a signed process can be spoofed - use CreateProcess with the suspended flag, inject a DLL, and overwrite the entrypoint with a JMP into the DLL. First call is a Sleep(1000) so allow it to run for 500ms, then replace your jump with the original code. Now you are running code in the DLL but the EXE hasn't been modified.
That's even without using the debugging APIs. Heck, they could patch your service to remove the check!
I am new to writing Windows Services so this is really strange to me. I have debugged an external library using a WinForm. The external library does some drive mapping, copying a directory structure, deleting the original directory, renaming the copied directory, and then removes mappings.
So, when I write up the service to initialize the external class and start the process, the service doesn't seem to be doing what I think it should be doing. It appears to be doing nothing and completely ignoring what is going on.
Is there anything I am missing? Does the external library need to have any Security attributes?
Update
Found out how to attach a debugger, per #Will's comment: System.Diagnostics.Debugger.Break()
Edit
It also helps when you copy your app.config file to the correct directory!!!
Not a lot to go on here. First, you can debug your service, which is what you should be doing rather than using a winform frontend to test your code.
The issue is either that your service is not created properly, or that you've got a security issue.
Your service will receive a start message, after which it must run its own code, often on a different thread (a Timer is a common way to do this).
If the service is touching a drive, the user account under which it executes must have rights to perform the operations it attempts. Try changing the user account under which it executes to your own and see if it starts working.