- This topic has 2 replies, 2 voices, and was last updated 18 years, 10 months ago by
.
-
Posts
-
Well, I have an interesting and irritating problem where I work, and I’m fed up enough to do something about it. (A personal solution.) To read a general description of my issue, check out this Windows newsgroup posting:
I’ve decided instead of writing a custom command shell to handle the problem (COMSPEC) that the network level solution is better since this would likely survive system upgrades and patches.
WinPktFilter seems like a good way to jump start such an effort as intercepting logon scripts (or anything other script) coming in over the network interface and modifying the data in the packet payload to suite according to rules an application (or NT service) applies to the script.
As I said, WinPktFilter seems like a good place to start, BUT…!!! I want to do a minimum proof of concept before I spend any money. Esp. $1500. So I’m looking for some direction in getting started using whatever is free. The helper libraries seem like they would support a proof of concept effort. Can anyone confirm this? Also, the PassThru sample app looked like the best place to get an idea of starting.
For proof of concept, I am only looking to run something from the command line that will:
(1) Sit and grab packets.
(2) Somehow identify which packets come from a remote command script.
(3) Assemble enough packets to reconstruct the entire login script or make sure that commands in each packet payload are not broken.
(4) Display those scripts to the console.I am not looking to mangle the script/packet data yet, just do enough proof of concept to see the packets and incoming login script assembled. If I can see the packet payload and correctly identify it, the rest will be pretty simple.
I have no Windows kernel mode experience, but I do have previous kernel/driver coding experience under VAX/VMS, so I can comprehend kernel concepts. I just have no idea where to start with C/C++ Windows programming other than the obvious developer environment (MSVC, etc.) and am looking for a little nudge in the right direction.
Thanks for any comments which will help me get started.
-pj
The helper libraries seem like they would support a proof of concept effort. Can anyone confirm this? Also, the PassThru sample app looked like the best place to get an idea of starting.
Yes, you can take passthru sample as base for this kind of solution. It transparently filters all incoming and outgoing packets for the specified network interface and has capability to modify them. In general I think you can implement relatively flexible solution on this way.
However, I would solve the concrete problem on a bit easier way. Let’s assume you using NT/2000/XP/2003 type of operating system. It’s not a great problem to create a driver which intercepts NT native API calls. Since creating a process on NT system requires calling a subset of native API (NtCreateFile, NtCreateSection, NtCreateProcess) you can hook one or all of them (there are several ways), check the file/process which is going to start and block/permit the operation basing on user reaction, registry setting, driver loaded settings or etc… On this way you can create a flexible solution for monitoring processes start up on your system. I would even surmise that you could find a ready solution for this approach in the Internet.
Since creating a process on NT system requires calling a subset of native API (NtCreateFile, NtCreateSection, NtCreateProcess) you can hook one or all of them (there are several ways), check the file/process which is going to start and block/permit the operation basing on user reaction, registry setting, driver loaded settings or etc… On this way you can create a flexible solution for monitoring processes start up on your system.
Yes, but what if you wanted to allow everything to run as “normal” except for one command? This is why I considered allowing the stream from the server but modifying it. There are commands coming from the server that I need. I only want to eliminate one of them (at present).
-pj
- You must be logged in to reply to this topic.