It's a little early in the day for me to be sarcastic, so I'll amuse myself by giving you a quick OS Theory primer. Take from it what you will.

In a general context, we could split user space (i.e. not OS kernel code or kernel modules) executable code into three categories: applications, processes, and threads. From my experience, applications are generally recognizable by way of interaction with the user of some form or another. This is why, say, CuteFTP is considered an application and Microsoft Schedule is considered a process. In terms of lower level OS interaction, there is no real noticeable difference except, perhaps, that applications tend to be more RAM and processor intensive.

A thread, on the other hand is a different animal than the process/application. A process (I'll refer to application/process as the same thing in this context), in terms of the OS, is allocated its own call stack, virtual memory, processor scheduling, etc. A thread could, in some ways, be thought of as "process-lite". Any process may be comprised of various threads, all of which share the stack, virtual mem, processor scheduling, etc. The code of the process itself handles internal communication between threads, without needing to bother the OS kernel.

There are various advantages and disadvantages to using processes vs. threads to accomplish atomic, simple, or low level tasks. Maximizing thread usage reduces the the need for expensive API calls to the kernel and saves the need for IPC (Inter-process communication) via shared memory, pipes, files, or database backends. This helps cut down on the potential for OS thrashing (i.e. "lag"). The downside of this, for savvy users and admins, is that there are generally no OS tools that help you determine exhaustively which threads are running and what they're doing - since the thread execution is handled within the process (i.e. black box to the OS), the only way to see what they're doing would probably require peering at assembly code dumped from the call stack (though one could probably write a program with heuristics for interpreting it).

Enter our discussion. All of the services running can be viewed at services.msc (the black box for the OS I mentioned earlier doesn't apply here, since these threads are registered through the OS and services is an OS process in Microsoft). Simply opening a list of running processes will show you the processes that are running, but you will not see the threads running within services process. Shutting down the services process is a terrible idea - it needs to be running (actually, the OS would probably respawn it if you killed it). However, the problem is that I can write a service (i.e. thread) and have it executing code, but not show up in the process list. If I wrote malicious code, I could create a service that would send a check-alive message to a malicious process every 30 seconds, and if the process were dead, I would respawn it. I could even write code as a service that would make various backups of the executable process, in case the user deleted them, and re-copy and re-spawn the process.

And, you would never see a whiff of that in the running processes list, since I'm running the service as a thread of services process. So, while it is unlikely that the malicious code writer would name the service "My annoying virus", savvy users can peruse that list for things that seem out of place. Or, they could shut down as many services that are non-essential to the OS operation as possible. Viewing a list of processes may well give you a hint (particularly if you look it up at CERT or something) as to how to eliminate the underlying problem, but, if a service is the underlying problem, the services.msc utility will allow you to look it right in the eye, so to speak.


You say the oddest things.

__________________
"Government big enough to supply everything you need is big enough to take everything you have... The course of history shows that as a government grows, liberty decreases."

-Thomas Jefferson

<SNIP>

I already know all that and it's irrelevant. In order for a running process to show up in Windows' services, it must have additional entries in the registry that mark its presence. Anyone who created a virus would certainly not bother to either. . .

1) Insert those additional entries into the registry, to make its presence more obvious, IF he tried to place that process in the service segment of the registry.

2) Make the process a service. He could simply place the process in HKLM/MS/Windows/CurrVers/Run. Processes placed there would not show in services, and most of the known viruses/worms list themselves there to run at startup.

If that isn't already obvious, try running a simple process, i. e. notepad.exe, on Windows. It certainly won't pop up in services, even though it's a running process. It will, however, show up in the process list.

If you can a run process and have it not show in Services, why would a virus writer not write a similar process (that hides itself from Services)?

WRONG. It's possible to insert a process entry into the services segment of the registry and have it NOT show up in services.msc.

OTOH, EVERY process running on the system, INCLUDING those associated with every service running (visible or not) can ALWAYS be seen in taskmgr, assuming an admin user is running it, and "Show All Processes" has been selected.

Hence, if you want a complete list of everything running on your system, there's no need to even look at services.msc. You can go straight to taskmgr, or run tasklist.exe at the command prompt, and that's it.

Running services.msc, OTOH, would show you an incomplete list. Therefore, it is an illogical/unnecessary step in searching for viruses.

__________________
Life only becomes meaningful at its extremes

-- S

I don't believe that at all. Your MO seems largely to be nitpicking and quibbling whether you fully understand something or not. Something tells me that if you had read and understood everything (anything) in there, you wouldn't be giving me a carte blanche of being right on all counts.

Huh? Why would a non-service process show up in the services windows, regardless of any tinkering with the registry? A service is specific in that it needs to contain at least two entry points (main and handler), run outside of any user context, and have no user interface (well, I reckon you could, but that would be a terrible idea). The registry is just a bloated ASCII file that tells the OS framework what to do - putting the path to executable in the registry neither causes it nor prevents it from being a service. You can start services at the command line if you want - a service is a service if is registered validly through the service manager.

You seem to believe that processes and services are the same thing (which is a strong indicator that you did not read or understand my previous post) and that the only difference between the two is (amazingly) which section of the registry contains their path and context information (and, FWIW, you're missing a bit of the path to the "Run" keys). I could take Winword.exe and slap an entry into the registry telling the OS to start it as a service, but that doesn't mean it's gonna happen.

What someone might do is create a lightweight service that runs occasionally, and communicates with a malicious process. This might "show up in services" (by which, I'm assuming you mean, be registered as a service) as something innocuous. Of course, who knows? Snot-nosed script kiddies might have another way of doing it - I only write useful code, so dreaming up ways to annoy people isn't really my main area of expertise. I don't know whether creating services that spawn processes and duck the process manager is the en vogue method of creating geeky havoc - only that it can be done, and relatively easily.

Yeah, no kidding. More compelling evidence that you neither read nor understood what I said. Where did I ever claim that a service would "show up as a process"? A service has to meet specific criteria to be a service - I don't know where you're getting the idea that I think whatever the hell I want can be a service. I've written services for Windows in C++ and C# - I promise you that, of the two of us, I have the better understanding of exactly how something "shows up in the services" (or, to be accurate, is registered and handled by the Services Control Manager).

Aside from the technical inaccuracy, that doesn't even make logical sense. "If you can run a process that's not a service, why not run a process that's not a service?"

Wow - go figure. The registry is a big fucking text file, and you're telling me that it's possible to put text in it? And that's supposed to prove something?

Again, you're missing the same point over and over again, your infatuation with the registry notwithstanding - the process tab on the task manager and the services.msc listing are not simply different and fun ways of categorizing processes - they are different animals (otherwise, why not throw them all into one big list and call it a day). Simply screwing up your registry by adding keys telling services to run as processes and vice-versa will not accomplish anything except dumping your malfeasance to a bunch of boot log error files.

Yes, once again, thank you for an ironic dose of the obvious. But, you're capitalizing the wrong word. You said "EVERY process" and I'll say to you "Every PROCESS running on the system" will appear in the process manager. Services will not (because, one more time for the peanut gallery) "They're. Not. The. Same. Thing." Any process will appear in the process manager. Any services will appear in the service manager. Seems reasonable enough to me (in fact, so intuitive, I don't understand why anyone would think that process and service are two words describing the same thing).

Well, those will give you a list of all processes running on your system. If you wanted a list of all services running, you would go to the list of services.

Exactly. That would give you a list of services that were running. If we wanted to know which processes were running, we'd probably be better served to see a list of those.

As an aside, I'm actually very amused by this. I feel like I'm having a conversation in which I've told you that I need to pick up some car parts and some groceries. You keep telling me to go to the store and when I explain that I will actually need to visit two stores, you keep telling me to go to store.

drgoodtrips: I just came from the auto-shop and now I need to get groceries.
solletica: That's stupid - you don't know what you're talking about. You should have gotten your groceries at the store you were just at.
drgoodtrips: But that was an auto store, now I need groceries.
solletica: That's stupid, they have groceries at the store you were just at.
drgoodtrips: No, I don't think that's right - I was just at an auto-parts store.
solletica: You don't know what you're talking about, you need to go to the store.
drgoodtrips: Okay, here' how it works. They have groceries in a grocery store and auto-parts in an auto-parts store. I need to go to two different stores if I want all of my groceries.
solletica: No, you need to go to the store if you want to buy products!
drgoodtrips:

__________________
"Government big enough to supply everything you need is big enough to take everything you have... The course of history shows that as a government grows, liberty decreases."

-Thomas Jefferson

They wouldn't. And almost all running viruses are non-service processes, which means that your suggestion of looking in services.msc was silly, because 95% of the time, a virus is not going to show up there.

However, every single virus that runs on a system will always have one or more separate processes associated with it (even if its executable image is similar to a valid process), which can be found in taskmgr.

This means that you can always track a running virus by looking for its executable image in the global process list (assuming, of course, the virus' executable isn't masquerading as an existing valid process), whereas if you look in Windows' services, you're likely to miss it.

And that was clearly the case here. The OP couldn't find anything by running services.msc, but after I told him to look in taskmgr, he discovered it.

But upon boot, Windows reads the entries in the registry, usu. under HKLM/System/ControlSet*/Services and registers all services listed there.

Not entirely true. To create a service, all you have to do is add in the necessary registry entries (which you can do as admin), and then reboot. You can certainly do it manually, either in code thru the WIN32 Registry API or by running regedit and adding entries there, while you're logged in as admin.




A service is just a Windows-specific abstraction for a specific task. Every service listed when running services.msc, however, is associated with one running process that can be seen in taskmgr. It's possible that one process can handle multiple services, but every service has one process, i. e. there is a many-to-one mapping between services and processes.

A runnable virus on a PC will always take the form of a separate process, regardless of whether it has a service associated with it (in most cases, it does not). Therefore, to track a running virus, all you need to do is look for its executable in the process list. The executable may masquerade as another valid EXE, but it will still be there.

__________________
Life only becomes meaningful at its extremes

-- S