|
Wow.....it's a good article BAB
|
|
|
|
|
You can kill MOST processes, not ANY process. If you're a normal user, you can only kill processes that your account launched. Even as an Admin, you cannot kill processes running under SYSTEM, nor any process above an Admin account.
|
|
|
|
|
It's very simple:
if(!isSystemCriticalProcess && userUnderWhichYourAppRunsHasRights){
showProcess = true;
canKill = true;
}
|
|
|
|
|
d@nish wrote: if(!isSystemCriticalProcess && userUnderWhichYourAppRunsHasRights){
showProcess = true;
canKill = true;
}
Thanks. I looked for what you gave me but couldn't find the showProcess and cankill properties. Could you be more specific?
|
|
|
|
|
Sorry, I was merely stating that you can see and kill a process only if it is not a system critical process and the user under whose credentials the application runs has the rights.
|
|
|
|
|
Firstly, there is NO process that will NOT be listed in task manager (assuming you've enabled "show processes from all users", and assuming you're not using some stone age version of Windows). There is basically no straight way for a process to "hide" itself from task manager.
You could do some highly esoteric stuff like patching the Kernel, and routing all the API calls through your layer of code, and filtering out the calls that are related to enumerating running processes, and then altering the enumerated result to hide your process... But there's Kernel Patch Protection, and that's going to give you a hard time.
But if you meant that you want to kill processes that are running under the system account, Dave and Luc have answered that question correctly.
Otherwise, short answer: Wrong question!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Rajesh R Subramanian wrote: there is NO process that will NOT be listed in task manager
Ahem. Rootkits do this quite successfully. Perhaps it's more accurate to say there is no kernel level process that will not be listed.
|
|
|
|
|
Pete O'Hanlon wrote: Rootkits do this quite successfully.
I explained that in my post. You need to patch the kernel to achieve that.
Pete O'Hanlon wrote: Perhaps it's more accurate to say there is no kernel level process that will not be listed.
No, there's no distinction at all. NO process can hide itself from being listed in task manager, with no regards to whether or not it is run at the kernel level.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Rajesh R Subramanian wrote: NO process can hide itself from being listed in task manager, with no regards to
whether or not it is run at the kernel level.
But that's exactly what a rootkit can do. Basically, it can intercept a call to list processes, and return a list of all processes other than itself. Task manager is a poor application to use to detect these things. An excellent article on rootkits can be found here[^]. (Take a look at figure 3, and the explanation beside it - it's particularly revealing for showing how to detect rootkits).
|
|
|
|
|
Pete O'Hanlon wrote: But that's exactly what a rootkit can do.
Yes, which is what I said too. Rootkit is just a fancy name. Whatever name is given to it, the ONLY way to achieve it is to patch the kernel. And I had to state that there's no regards to which ring the process is run at, because it doesn't matter - the enumeration will contain all the processes.
Pete O'Hanlon wrote: Basically, it can intercept a call to list processes, and return a list of all processes other than itself.
Like I said, I already explained this in my first reply to the OP.
Pete O'Hanlon wrote: Task manager is a poor application to use to detect these things.
Well, yes. Because task manager was never developed to detect such things. 
I'll take a look at the article, but I write code for an anti-virus company, and stroll through, and debug code that has to fight with malware of all sorts on a daily basis.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Fair enough - you're an expert in this side, but you did state quite clearly that "there is NO process that will NOT be listed in task manager". That's pretty unequivocal, and perhaps you've got some nuance that I'm not aware of, but we've gone from no process to no unpatched kernel process, which is not the same thing (yes I appreciate that you clarified in your original answer, but the fact remains that there is are processes that will not be listed - and a bald first statement like that leads to people assuming this is true in all cases). I know it seems like I'm splitting hairs here, but there is a difference, and I am nothing if not anal about these things.
|
|
|
|
|
Well, my point is that after you patch the kernel, it is not Windows anymore - it's not task manager anymore. The OS itself is a virus, because all the calls to the kernel are intercepted and can be "adjusted" by the patch code.
OK, may be I should have said: "On a machine with kernel that hasn't been patched or infected by malicious code, it's impossible for a process to hide from the task manager".
And, you sir are anal about things. But there's nothing wrong with it, because serious programmers WILL BE anal about things. As a fellow-nerd, I can appreciate it.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
By what method have they been hidden?
|
|
|
|
|
It's not method that hides. There are two games KnightOnline and Metin2 that are not shown in Processes list and task manager. So, as I can't see them in Processes I can't close them.
|
|
|
|
|
Yes, I meant method as in "way" instead of "function".
How do KnightOnline and Metin2 hide their process?
|
|
|
|
|
David1987 wrote: How do KnightOnline and Metin2 hide their process?
I don't know how they do it. All I know and want is to close them
|
|
|
|
|
I am trying to connect to a tcp listener, after I hit the clint.Connect(server, port) it throughts a SocketException
public void Connect(String server, String message)
{
try
{
StreamWriter sw;
StreamReader sr;
int port = 5000;
TcpClient client = new TcpClient(server, port);
client.Connect(server, port);
sw = new StreamWriter(client.GetStream());
sr = new StreamReader(client.GetStream());
sw.WriteLine(message);
sw.Flush();
string rtnMsg = sr.ReadToEnd().Trim();
}
catch (ArgumentNullException e)
{
Console.WriteLine("ArgumentNullException: {0}", e);
}
catch (SocketException e)
{
Console.WriteLine("SocketException: {0}", e);
}
catch (IOException e)
{
}
catch (NullReferenceException e)
{
}
Console.WriteLine("\n Press Enter to continue...");
Console.Read();
}
Any help would be really helpful.
|
|
|
|
|
The reason this happens is because you've already attempted to establish a connection in your constructor. The exception you're getting will be indicating that the port's already in use.
|
|
|
|
|
It is just a method which is call by a thread, the method is passed the server IP to connect to.
It throws an exception even when connecting only to one IP
|
|
|
|
|
Did you read what I said carefully? Basically, when you call new TcpClient(address, port) you are establishing a connection at that point. You can remove the Connect call as you've already established your connection. See this[^] for more details.
|
|
|
|
|
Just let it go Pete...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
|
I think you link should help him out. I went thru it and msdn is always helpful
|
|
|
|
|
Paul Harsent wrote: TcpClient client = new TcpClient(server, port);
client.Connect(server, port);
I'm with Pete here; you basically have provided the same information (server, port) twice; that would not make much sense, would it?
The documentation[^] provides an example, it does not have a Connect() call.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
I have a program that I'm trying to multithread. It works correctly on a single processor. All I had to do was change the for loop to Parallel.For and add ");" at the end. Basically, the structure is as follows:
Variables (V) that do not get modified inside the loop, including a LinkedList<BigInteger> that does.
Parallel.For (0, 5, j => {
BigInteger Variable that relies on j and another from (V - outside loop).
foreach (BigInteger k in numbers) {
Local Variables.
{
Add k to LinkedList.
Console.WriteLine(k and other data.);
}
Console.WriteLine(Summary count per loop.);
});This parallel loop is missing a few values when multithreaded. However, if I put a write statement just before the IF to capture everything (commented out), it works. The summary count comes up accurate every time. If I comment it out, it fails, every time starting at higher values of k across all j. Basically, it starts working and slowly degrades. It seems to be that the write statement is slowing it down for it to work.
Do I need a more threaded way of adding to the LinkedList array or am I missing something else? Any suggestions would be appreciated.
NB - Can't submit code and this is console programming without the use of Visual Studio. Don't ask!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
