Is there any tool that can monitor/capture/sniff named pipe traffic?
Even when max instance = 1?
There's no official way.
Use API hooking. Hook ReadFile and/or WriteFile, maybe also CreateFileA/W (assuming that the app is a pipe client) and do the necessary things on their invocation.
Microsoft has also its own library for API hooking - Detours .
Related
The official FastCGI documentation says that stdin is repurposed as a listening socket when a FastCGI module is started. That's great on Linux, where stdin and sockets are all ints, but I don't think it could it work on Windows, where stdin is a FILE*, and a socket is a HANDLE.
Since Windows servers do support FastCGI, someone has either found a way to make them compatible, or redefined the system for that OS. My Google-fu doesn't seem to be up to locating how though. Where can I find documentation on it?
FastCGI defines only the message exchange protocol, but people behind FastCGI also provide one implementation of that protocol for C++. In this implementation your app must use provided FCGX_Request object to rewire three provided FCGX_Stream objects to the usual ones (cin, cout, cerr). But I suspect that you don't have to rewire the streams, and can use them directly. Check out this FastCGI Hello World to see how it's done.
So, your app does not see HANDLE or FILE*. It sees instead fcgi_streambuf, which inherits from std::streambuf. The way the previously mentioned protocol is implemented is just a detail that you're not supposed to be concerned with. The implementation gets hold of a stream of bytes and provides it to the app, and also the other way around.
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!
Is there any way to hook all disk writes going thru the system, and receive the file names of whatever's being modified, using the Win32 API? Or is this something that would require writing a driver?
You can't do this in user mode, it needs to be kernel mode and so that means a driver. You need a File System Filter Driver.
If you don't care about intercepting the actual data, and only want to know which files are being modified/created/deleted then you can use the ReadDirectoryChangesW API to get that info from userland. Note however that it's one of the hardest functions to use effectively and efficiently, and you should be familiar with IOCP to use it correctly.
I have a program that does some networking using Winsock, and one of our requirements right now is to port over our program to Linux. The only thing stopping us from doing this is Winsock.
My question is: How easy can I port this over to a Linux implementation?
Are there any pitfalls I should be aware of, and if I simply include the appropriate header files, what sort of things will I have to be sure to handle?
Thanks for any help!
I'd post code but I can't unfortunately due to legal reasons.
But, our code does use the following:
WSAStartup(..)
WSACleanup(..)
Socket(..)
sendto(..)
recvfrom(..)
ioctlsocket(..)
setsocketopt(..)
Based on that list of functions, things should more or less just work. Add #if _WIN32 around the calls to WSAStartup and WSACleanup (the linux equivalent is to not do anything, the sockets library is initialized automatically).
You also might need some OS-dependent code when setting socket options, some of them are the same, some aren't, and the types might be different.
It will depend if you use any windows specific networking functionality or if you're just using mostly the mostly BSD compatible API.
So, if you're using overlapped I/O and I/O completion ports and other advanced parts of the Winsock API then things will be very difficult to port and if you're just using the BSD compatible stuff then it should be easy to write a thin translation layer or even just have the winsock startup and shutdown stuff inside a windows specific ifdef...
This may help: http://tangentsoft.net/wskfaq/articles/bsd-compatibility.html
The only calls that make porting difficult are the WSA* calls.
WSAStartup() -> nop
WSACleanup() -> nop
Socket/setsockopt -> socket/setsockopt
Under *nix, sockets are blocking by default and it's not necessary or possible to use that weird setsockopt call to fiddle with it.
ioctlsocket -> ioctl
Under *nix we don't like asynchronous sockets much and prefer to use the select() system call.
---- Rest of this answer seems only to apply to Win95 compatible winsock ----
Unfortunately as the original socket() in Winsock was broken in some cases, you probably used WSASocket() and so have to convert those calls.
Without seeing code, it's tough to say how easy it is. But you should be able to replace winsock calls to analogs in sys/socket.h.
we have a windows service running and we also have a console application that we use to configure this service, we also have an option to see some log being recorded.
The very ugly thing with this is that this communication is made by a text file, the console app writes to a text file and the service reads it and vice versa.
What would you use for this communication? TCP/IP is not an option because the console app will be used for the local running service only.
Windows API SendMessage should be the way to go?
thanks!
I would recommend WCF as the first thing to consider for all comms on windows if using .net as its built for this kind of thing and its relatively easy to use. Since you're excluding TCP, I'd suggest using the Named Pipes Binding.
There are also an number of windows comms apis available for intra-machine comms. Named Pipes (as mentioned), MailSlots, Shared Memory (Memory Mapped files) etc.
My suggestion would be be use Named Pipes either with WCF or natively.
You run less risk of deadlocks if you use non-blocking methods of message passing. PostMessage, or SendNotifyMessage are better than SendMessage because they don't block the caller.
But they depend on the service having a window handle. Does it?
You can also use the WM_COPYDATA message, to pass more than just a wParam a lParam. If you use this message with PostMessage, you need to be careful not to free the memory until the receiver is done with it. It's safest to use SendMessage for WM_COPYDATA.
Shared Memory? See here for an article on Codeproject, here's another fastipc article on the same site. There's a blog entry detailing on how to use a memory mapped file for sharing via a wrapper.
Hope this helps,
Best regards,
Tom.