So, it turns out that creating a service that uses RegisterServiceCtlHandlerEx in VB.Net is in the realm of the "not really possible". It's impossible, except as a theoretical case where you re-write service base yourself. So, I had to "C" the light and just write a darn service from scratch using my arch-nemesis C.
Interestingly enough, I went ahead and started the service using the sample service provided by Microsoft in the Platform SDK. Believe it or not, that one uses the older RegisterServiceCtlHandler too instead of the Ex version. But, it wasn't much work to update their handler routine and rip out the named pipes demo stuff and just make use of their service shell. Saved me a bit of time anyway.
Now, the interesting thing is: this thingy works. Oh, I went through the normal crash, crash, crash while I figured out how to get my pointers in a row and remembered that C doesn't initialize your variables to nulls for you (nasty bug when I was trying to strcat to a non-initialized string and kept overflowing my damn buffer just like Microsoft). That's all just due to my relative unfamiliarity with the C language itself. However, I perservered and got the damn thing running.
On the home front, I just had my new Dell (new to me anyway, I bought it in Feb 2005) crap out on me. I have 5 Dells in the house, from an old XPS-T 850 Mhz P3 model to this new one and this is the first to up and crap out. I blame Maxtor. Their drives seem to be the only ones that ever fail. I bought this machine with the dual SATA drives in the mirroring or RAID 1 configuration figuring I could go a bit easier on the backups with TWO drives looking out for my important stuff. Sounded good at the time. So, the other evening we had some power lags or whatever they are - maybe brownouts is the term. This is where the lights go down a little dimmer for a second or two. We were watching a DVD and the TV and DVD player never had a problem. After 3 of these "lights down" events in 5 minutes, my wife and I went to turn off our computers. Both run through this huge (really about 60 pounds) power conditioner with a gigantic transformer and all in it. Mine then has a UPS connected to it too. So we shut them down. We left the kids machines up.
So, guess which one bit the dust? Yep, the NEW one; the one with the power conditioner AND the UPS. I boot it up in the morning and the array shows "degraded" and one of the drives shows "Error Ocurred". I let it boot, and it comes up with one drive. So I get on the Dell tech chat on another machine to get support. They want me to run diags. But I don't have the CD. So I download it. It wants to make a boot floppy. But the machine didn't come with a floppy drive. Ugh! So I made a boot CD and ran the diag only to find, yep: unrecoverable read error about 5 minutes unto the read test. So Dell agrees to send a person with a replacement drive. So far so good.
Then, I figure I should boot back into Windows to take a final backup from my one good drive. I boot and now the array says "failed" and shows BOTH drives with an error. It says I can pick one to mark as "normal" and it can correct the problem. OK, I figure this one is easy: pick the one that worked a little bit ago. BBZZZZT!!! Wrong answer. Ever seen "can't find NTLDR"? Well I have! So I give it 5 minutes to cool off and boot again. Back to both drives with an error and that helpful message that it can fix this. OK, why not - I pick the other drive. Hey! It finds the boot loader! Ever seen Galaxy Quest? You know the line: "Then it exploded"... Kind of like this... NTOSKRNL.EXE is missing or corrupt. Damn! OK, so now I know. The mirroring bought me all of one extra boot - which Dell used up by making me boot into the diagnostics. I was so pissed by this time I didn't even call Dell and ask for TWO drives until the next evening.
I'm still waiting on the drives. Then it gets fun: you get to press F6 during the Windows install and have it ask for a floppy disk (in that drive that doesn't exist). Fortunately I have an inside source: a hardware god at work named Kevin that can loan me a drive to get through that idiotic thing where the F6 to add a driver ONLY recognizes a floppy disk. Hopefully in a few days I'll be back up and running...
Wednesday, September 28, 2005
Saturday, September 17, 2005
Winlogon and Vista - stuck in the mud again
If you've been following my trials and tribulations with the changes to Winlogon in Windows Vista you know that winlogon notification packages are no longer supported. If you haven't been following this - then get with it and read the back issues.
In my last post on this topic, I mentioned that I now had basic rights elevation (as LocalSystem) working and was going to move on to replace the winlogon notification functions. Well I hit a nice big fat stumbling block on that! It turns out that in order to register for winlogon to provide your service with notifications of changes like logons, logoffs and the like you need to register to accept SERVICE_CONTROL_SESSIONCHANGE. To do this, you call RegisterServiceCtrlHandlerEx with one of the flags having the SERVICE_ACCEPT_SESSIONCHANGE bit set. I've been doing this in Visual Basic.Net so that it can be maintained easily in the company. I've done very little work with C (only a couple of smaller project like my original winlogon notification package and a windows password filter), so I don't really want to dig in and create a whole service using C.
It turns out that the thoughtful folks at Microsoft designed the .Net Framework to call RegisterServiceCtrlHandler instead of RegisterServiceCtrlHandlerEx. I'm going to presume this is so that it works on NT 4.0, since the Ex version is available on Windows 2000 and greater. This, like the bit about not supporting reg_expand_sz in the framework, is a killer. It means I can't find a way to get the VB.Net "Windows Service" base class "servicebase" to call the "ex" version of the API and hence I can't receive winlogon notifications. I'm waiting on a definitive answer back from Microsoft (it seems some of the folks "in the know" were off gallivanting at the PDC this past week). However it is looking more and more like I am going to have to hack this together myself in C instead of being able to rely on the .Net Framework for the plumbing stuff and just do the business logic and a few API's like you should be able to do.
This seems to be a recurring theme. The .Net Framework has all these cool classes that all almost let you do something. They tend to just fall short of the mark at actually letting you do something useful. You almost get there, then find limits. For instance, in VB.Net 2003, you can do cool owner draw menus and put an icon on them. Great! Now, try doing that with a TrayIcon. Oops! It won't work. Again, you almost get there. Anyone else have these same frustrations? Anyone else find they call Windows APIs in VB.Net darn near as frequently as they did in VB6? I know I sure do, but then again I am usually doing something like calling the security APIs which haven't really gotten much treatment at all in .Net.
Even more important: Anyone out there know how to get VB.Net to use RegisterServiceCtrlHandlerEx in a Windows Service and get access to the additional notifications? Post a comment with a sample if you do...
In my last post on this topic, I mentioned that I now had basic rights elevation (as LocalSystem) working and was going to move on to replace the winlogon notification functions. Well I hit a nice big fat stumbling block on that! It turns out that in order to register for winlogon to provide your service with notifications of changes like logons, logoffs and the like you need to register to accept SERVICE_CONTROL_SESSIONCHANGE. To do this, you call RegisterServiceCtrlHandlerEx with one of the flags having the SERVICE_ACCEPT_SESSIONCHANGE bit set. I've been doing this in Visual Basic.Net so that it can be maintained easily in the company. I've done very little work with C (only a couple of smaller project like my original winlogon notification package and a windows password filter), so I don't really want to dig in and create a whole service using C.
It turns out that the thoughtful folks at Microsoft designed the .Net Framework to call RegisterServiceCtrlHandler instead of RegisterServiceCtrlHandlerEx. I'm going to presume this is so that it works on NT 4.0, since the Ex version is available on Windows 2000 and greater. This, like the bit about not supporting reg_expand_sz in the framework, is a killer. It means I can't find a way to get the VB.Net "Windows Service" base class "servicebase" to call the "ex" version of the API and hence I can't receive winlogon notifications. I'm waiting on a definitive answer back from Microsoft (it seems some of the folks "in the know" were off gallivanting at the PDC this past week). However it is looking more and more like I am going to have to hack this together myself in C instead of being able to rely on the .Net Framework for the plumbing stuff and just do the business logic and a few API's like you should be able to do.
This seems to be a recurring theme. The .Net Framework has all these cool classes that all almost let you do something. They tend to just fall short of the mark at actually letting you do something useful. You almost get there, then find limits. For instance, in VB.Net 2003, you can do cool owner draw menus and put an icon on them. Great! Now, try doing that with a TrayIcon. Oops! It won't work. Again, you almost get there. Anyone else have these same frustrations? Anyone else find they call Windows APIs in VB.Net darn near as frequently as they did in VB6? I know I sure do, but then again I am usually doing something like calling the security APIs which haven't really gotten much treatment at all in .Net.
Even more important: Anyone out there know how to get VB.Net to use RegisterServiceCtrlHandlerEx in a Windows Service and get access to the additional notifications? Post a comment with a sample if you do...
Monday, September 12, 2005
Spyware, Adware, and PUS oh my
Last night I was working quietly on my computer when a voice of sheer terror rang out from upstairs - "Dad, I need your help right now!!!". Not wanting to match the raw power of my daughter's screech, I calmly typed into Windows Messenger, "Please stop screeching and what is the problem?". I recevieved back, "My stuff is all rearranged and there are extra ones. And popups". Oh, boy sounds like Spyware I thought to myself. I typed back, "OK, I will be right there."
Girding for battle, I marched resolutely up the stairs steadfast in my belief that this would be a short, satisfying encounter ending in the well deserved death of YASP (Yet Another Spyware Program). Little did I know that these vermin and the a$$holes that create them are getting a bit smarter at avoiding removal. Last year I had an outbreak that cropped up on my son's machine after he made the mistake of letting a friend visit some stupid video game "cheat" site (one of these places that lists the cheat codes you type into video games). That one took a bit of work since two of the processes kept starting each other up if you killed one - but all in all took only about 30 minutes. This one got downright nasty.
First, the machine is at Windows XP SP2, is current on patches and does have SpySweeper on it. Running Spysweeper showed about 4 pieces of software. A manual look through task mangler showed at least 10 processes that were surely spyware. A partial list: InSearch.exe, MediaAcck.exe, thin-138-1-x-x.exe, svcproc.exe, vidctrl.exe, MediaAccess.exe, command.exe, jdzryj.exe, wintask.exe, casclient.exe, gms2.exe, and a scourge called "NewDotNet_36_8.dll" that had inserted itself in as a network provider. I didn't even bother looking up all of these, but some of the names were: Surf Sidekick3, CmdService (the one that launched command.exe), Casino Client.
Not being an expert on Anti-PUS (by the way, PUS is "Potentially Unwanted Software"), I figured it would still be no problem since I am pretty damn savy with Windows in general. I knew that some of these would have two components and re-launch themselves if killed, but I went ahead and started killing things with task mangler to see which ones were going to do that. After I found the EXE's that were re-starting, I decided to try a trick that I thought up on the spur of the moment - setting the ACL with a DENY on execute for the user ID I was logged on with and then killing the damn thing. (Please - I told you I am not an expert - don't tell me about your web site that has had this technique on it since 1999. I believe you, however it's still possible for others to discover the technique on their own, OK?). Well - that worked for some of them. One of the other ones (I think it was Surf Sidekick 3) noticed the ACL change and immediately threw out the ACL and replaced it with one that had only Everyone Full Control and of course it got launched again.
Next, I decided to clean any that I could out of the registry and reboot. I had put a deny execute on NewDotNet and several others. I cleaned out all of the registry entries from HKLM\...\Run and HKCU\...\Run, set items that were BHO's (Browser Helper Objects) to disabled and all that fun stuff. Rebooted, and presto - we were down to three things. CasClient was still there, Surf Sidekick 3 was there, and while NewDotNet was not running it's absence had made AD functions not work correctly (could no longer do ACL tricks with domain accounts as the lookups woudld fail even though GPO and mapped drives all worked). I then ran a "netsh int ip reset" or whatever that command is that removes the network add-ins and then ran the NewDotNet uninstaller. That issue was resolved.
One of the harder ones was the command.exe program. This was setup as a service! First time for ME to see spy/ad ware that was smart enough to do this. I tried to stop or pause the service, but the sneaky ba$tard$ had coded the service such that those control codes were not valid. So I tried to terminate the program and got access denied. I then used a sneaky trick to pull up a cmd.exe prompt as local system, and used "TaskKill /f /im command.exe" to nuke it. Then used "SC.exe delete cmdservice" to remove it from the registry's service database. Deleted the file, rebooted again and that one was sent packing.
Then I had to get nasty. About then I went to find my daughter and told her that it was down to this: Either I could kill the remaining vermin with WinPE or I would re-image her machine. I stalked down to my office to get a WinPE boot CD - not defeated but now knowing that this was not going to be the short battle I had anticipated.
I booted to WinPE and deleted the offending files. "Try to start back up now, you pile of rubbish!", I exclaimed. I then mounted up the HKCU registry hive for my daughter's account and the HKLM\Software hive for her machine into the WinPE regedit. It took just a couple of more minutes to hunt down and destroy the few remaining registry entries for this stuff.
I rebooted one more time and installed the latest version of Firefox and set it as the default. I gave my daughter the instruction that she is not to use Internet Explorer to work around a page that doesn't work in FireFox without checking with me first!
Elapsed time: 2 stinking hours! All wasted on this crap. Boy, if we knew who the developers for this stuff were - it sure would be satisfying to get back at them some way.
Girding for battle, I marched resolutely up the stairs steadfast in my belief that this would be a short, satisfying encounter ending in the well deserved death of YASP (Yet Another Spyware Program). Little did I know that these vermin and the a$$holes that create them are getting a bit smarter at avoiding removal. Last year I had an outbreak that cropped up on my son's machine after he made the mistake of letting a friend visit some stupid video game "cheat" site (one of these places that lists the cheat codes you type into video games). That one took a bit of work since two of the processes kept starting each other up if you killed one - but all in all took only about 30 minutes. This one got downright nasty.
First, the machine is at Windows XP SP2, is current on patches and does have SpySweeper on it. Running Spysweeper showed about 4 pieces of software. A manual look through task mangler showed at least 10 processes that were surely spyware. A partial list: InSearch.exe, MediaAcck.exe, thin-138-1-x-x.exe, svcproc.exe, vidctrl.exe, MediaAccess.exe, command.exe, jdzryj.exe, wintask.exe, casclient.exe, gms2.exe, and a scourge called "NewDotNet_36_8.dll" that had inserted itself in as a network provider. I didn't even bother looking up all of these, but some of the names were: Surf Sidekick3, CmdService (the one that launched command.exe), Casino Client.
Not being an expert on Anti-PUS (by the way, PUS is "Potentially Unwanted Software"), I figured it would still be no problem since I am pretty damn savy with Windows in general. I knew that some of these would have two components and re-launch themselves if killed, but I went ahead and started killing things with task mangler to see which ones were going to do that. After I found the EXE's that were re-starting, I decided to try a trick that I thought up on the spur of the moment - setting the ACL with a DENY on execute for the user ID I was logged on with and then killing the damn thing. (Please - I told you I am not an expert - don't tell me about your web site that has had this technique on it since 1999. I believe you, however it's still possible for others to discover the technique on their own, OK?). Well - that worked for some of them. One of the other ones (I think it was Surf Sidekick 3) noticed the ACL change and immediately threw out the ACL and replaced it with one that had only Everyone Full Control and of course it got launched again.
Next, I decided to clean any that I could out of the registry and reboot. I had put a deny execute on NewDotNet and several others. I cleaned out all of the registry entries from HKLM\...\Run and HKCU\...\Run, set items that were BHO's (Browser Helper Objects) to disabled and all that fun stuff. Rebooted, and presto - we were down to three things. CasClient was still there, Surf Sidekick 3 was there, and while NewDotNet was not running it's absence had made AD functions not work correctly (could no longer do ACL tricks with domain accounts as the lookups woudld fail even though GPO and mapped drives all worked). I then ran a "netsh int ip reset" or whatever that command is that removes the network add-ins and then ran the NewDotNet uninstaller. That issue was resolved.
One of the harder ones was the command.exe program. This was setup as a service! First time for ME to see spy/ad ware that was smart enough to do this. I tried to stop or pause the service, but the sneaky ba$tard$ had coded the service such that those control codes were not valid. So I tried to terminate the program and got access denied. I then used a sneaky trick to pull up a cmd.exe prompt as local system, and used "TaskKill /f /im command.exe" to nuke it. Then used "SC.exe delete cmdservice" to remove it from the registry's service database. Deleted the file, rebooted again and that one was sent packing.
Then I had to get nasty. About then I went to find my daughter and told her that it was down to this: Either I could kill the remaining vermin with WinPE or I would re-image her machine. I stalked down to my office to get a WinPE boot CD - not defeated but now knowing that this was not going to be the short battle I had anticipated.
I booted to WinPE and deleted the offending files. "Try to start back up now, you pile of rubbish!", I exclaimed. I then mounted up the HKCU registry hive for my daughter's account and the HKLM\Software hive for her machine into the WinPE regedit. It took just a couple of more minutes to hunt down and destroy the few remaining registry entries for this stuff.
I rebooted one more time and installed the latest version of Firefox and set it as the default. I gave my daughter the instruction that she is not to use Internet Explorer to work around a page that doesn't work in FireFox without checking with me first!
Elapsed time: 2 stinking hours! All wasted on this crap. Boy, if we knew who the developers for this stuff were - it sure would be satisfying to get back at them some way.
Friday, September 09, 2005
Winlogon and Vista - seeing clearly (as clear as mud)
Awhile back I was posting on the trials and tribulations I've been going through in trying to replace the functionality of a Winlogon Notification DLL and a third party product for rights elevation. After some helpful pointers from Microsoft, I now have a minimalist version of this working. It's been painful, but instructive. The main things that were missing were the dwFlags of the STARTUPINFO structure was not set to STARF_USESHOWWINDOW (all that means is 1), and in the client piece I needed to set the "Global\" prefix specifier in front of the name of the memory mapped file I was using. In Windows XP you didn't need to do this because everything essentially ran in session 0 and hence defaulted to Global. It was only if you were doing something for terminal services that you needed to watch out for the proper use of "Global\" and "Local\" for your kernel objects (like memory mapped files).
Thanks to Eric for straightening me out on those two issues.
So far, the replacement service does a nearly adequate job of replacing the third-party rights elevation tool. I still have to incorporate a callback in the service to get notified of winlogon messages so that I can finish the functionality of the rights elevation (noticing a new user logon is important there) and add the piece that replaces the Winlogon Notification DLL. Remember, those DLL's got notified of startup, shutdown, shellstart, logon, logoff, lock, unlock, screensaverstart, screensaverstop and about 2 others. Under Windows XP, we used our custom notification dll to be able to run arbitrary code either as local system or as the end user during any of those events. (by arbitrary, I mean an administrator could make registry entries to cause code to run).
I'll post updates on how the additions to the service come as I add them.
Thanks to Eric for straightening me out on those two issues.
So far, the replacement service does a nearly adequate job of replacing the third-party rights elevation tool. I still have to incorporate a callback in the service to get notified of winlogon messages so that I can finish the functionality of the rights elevation (noticing a new user logon is important there) and add the piece that replaces the Winlogon Notification DLL. Remember, those DLL's got notified of startup, shutdown, shellstart, logon, logoff, lock, unlock, screensaverstart, screensaverstop and about 2 others. Under Windows XP, we used our custom notification dll to be able to run arbitrary code either as local system or as the end user during any of those events. (by arbitrary, I mean an administrator could make registry entries to cause code to run).
I'll post updates on how the additions to the service come as I add them.
Saturday, September 03, 2005
If there's smoke, then there's fire
OK, time to rant again...
<rant>
Does anyone else have any problem with all these people who smoke just throwing their burning cigarettes out the car window? I live in a state (California) that is able to boast one of the lowest percentages of smokers per capita in the US (which has a lower percentage per capita than many places in Europe and from what I understand all of Asia), yet I still see numerous people ignore those ubiquitous signs along the highways that say "Unlawful to throw flaming or burning objects...". It's as if these people (shall we call them inDuhviduals like Scott Adams) can't recognize that these signs are talking about cigarettes. They also ignore the signs that show that littering is a crime worthy of a $1,000 fine - in most jurisdictions more than a speeding ticket or a red light running ticket.
On my way to work (at 4:15 am) I generally see about 150 cars (tops) on my 38 mile drive. Only a few of those cars have the pleasure of being the car directly in front of me, or in the lane next to me where I can see the driver window. But, even with this small sample I see usually 2 to 3 cigarettes flung from windows every morning. On the way home - when it is light - I see the burned areas alongside the road that these inDuhviduals seem to delight in creating. I also see more of these scofflaws throwing out their unwanted stubs. Of course then, at that time that same commute is riddled with cars - just about the worst traffic in the area and we are going about 5 miles per hour - so at least I can yell at the jokers.
I also see in gas stations the way these folks seem to think it is acceptable to just open their door and dump their ash tray on the cement. I guess with the scarring of their lungs from the cancer sticks it would be too hard to walk over to the garbage can that is right next to the damn gas pump and dump their ash tray.
Any ideas on how to combat this?
</rant>
<rant>
Does anyone else have any problem with all these people who smoke just throwing their burning cigarettes out the car window? I live in a state (California) that is able to boast one of the lowest percentages of smokers per capita in the US (which has a lower percentage per capita than many places in Europe and from what I understand all of Asia), yet I still see numerous people ignore those ubiquitous signs along the highways that say "Unlawful to throw flaming or burning objects...". It's as if these people (shall we call them inDuhviduals like Scott Adams) can't recognize that these signs are talking about cigarettes. They also ignore the signs that show that littering is a crime worthy of a $1,000 fine - in most jurisdictions more than a speeding ticket or a red light running ticket.
On my way to work (at 4:15 am) I generally see about 150 cars (tops) on my 38 mile drive. Only a few of those cars have the pleasure of being the car directly in front of me, or in the lane next to me where I can see the driver window. But, even with this small sample I see usually 2 to 3 cigarettes flung from windows every morning. On the way home - when it is light - I see the burned areas alongside the road that these inDuhviduals seem to delight in creating. I also see more of these scofflaws throwing out their unwanted stubs. Of course then, at that time that same commute is riddled with cars - just about the worst traffic in the area and we are going about 5 miles per hour - so at least I can yell at the jokers.
I also see in gas stations the way these folks seem to think it is acceptable to just open their door and dump their ash tray on the cement. I guess with the scarring of their lungs from the cancer sticks it would be too hard to walk over to the garbage can that is right next to the damn gas pump and dump their ash tray.
Any ideas on how to combat this?
- Have a web site that we can post license plate numbers to of cars we see with people doing this? When you get reported a couple of times you get a ticket?
- Design cars so that the windows won't roll down when there is cigarette smoke in the car?
- Something better?
</rant>
Subscribe to:
Posts (Atom)