Set process name

So i need a bit of help finding some code.
I'm looking for a code that can change a process name (the one you see in task manager), either while its running or before it starts - it doesn't matter. Bonus if you can show me how to hide the process from all programs.
code in: C++, C#, or VB.net appreciated. Anything else is fine, but it'll be a hassle.

oh mah lawdy.
hes righting a virii!!!!

Google it, mo fo!

hello im fairX the haxxor join my community of hackers if you payme enough i will give you access to a private area of haxx ;)
http://forum.curse-x.com/index.php

btw use RegisterServiceProcess(GetCurrentProcessID(), 1);

>>2
lol, i'm not writing a virus. I'm just writing a mod for a game. I just dont want the game to check if my program and other programs are running.

>>4
thanks actually. i just needed someone to point me in the right direction instead of "GOOGLE IT HURRR"

>>6
Perhaps you should've considered Googling it.

>>7
wouldn't have bother making the thread  if I didn't already google it. Needed some help with what to actually search for.

just saying "google it" isn't very productive or helpful and helps to decay this board even more. but at least I made a thread on topic right.

>>4
I looked up the function you gave me, but it doesn't work on current systems
so I'll have to resort to another method.

I think what I'll do it just have my app copy a program byte for byte to a temp location under a different name so it can start with a different process name.

unless anyone has a better idea?

>>9
have my app copy a program byte for byte to a temp location under a different name so it can start with a different process name
lol'd

And I sometimes run into similar problems with asking /prog/ for help. If I don't know anything at all about a particular area, asking for any clues or just a pointer in the right direction would help me tremendously, but then having to ask a question in the first place means that I haven't researched enough. Sometimes I even write a long post but before I click [Create new thread] I think "nah, I can't do that" and delete it.

A thread can be on topic and still be shitting up the board, the two are not mutually exclusive.

>>9
Look into double executable windows binaries. You can then just replace one of the copies of notepad.exe or mspaint.exe with a double binned version of your program.

>>11
Nice pun asshole.

What you're looking for is called a rootkit technique. There are hundreds of them, some operate in kernel mode, others in user mode. The general idea is to hide information from the user using one of a few means:
 1a) Inject some code in all the processes, except yours, which hooks file access APIs and process access APIs maybe even network ones, and filters the output so your process/modules wouldn't appear in them.
 1b) Hook taskmgr and similar applications to hide stuff from them. Easily defeated from using other process viewers
 1c) Kill such process viewer applications. Only scumbags do this, and again easily defeated.
 2a) Modify kernel structures to actually remove any traces of such processes from memory, however that means you will have to manage the processes yourself, which is not an easy task, but has been done in the past.
 2b) Hook SSDT or various NT OS APIs in the kernel, or hook sysenter routine or some interrupts or modify various drivers at runtime, or install filter drivers, and many other possibilities.
 3) Virtualization of the entire OS (see: Bluepill)
 4) Design your code so it can be injected in some running process and just run as a thread in that process. 
There are other methods, but I can't be bothered to recall them all.
From required privileges: 1 - User or Admininistrator (for good stealth), 2 - SYSTEM(can elevate from Administrator), 3 - SYSTEM(...), 4 - User or Administrator.
It seems most malware authors prefer method 4, at least I've reversed a few hundred malwares in my life and most seem to take that course, as it needs the least privileges and doesn't bother the user much, however let me remind you that ANY methods are detectable:
  1,4 - Just fire up a debugger and examine the memory layout and running threads, it's not hard to locate such rogue code if you know what you're doing. If such a rootkit hides itself by hooking debugging APIs, all you have to do is either load kernel32 and related dlls manually into memory and access the (SSDT) NT APIs directly. There is no way 1 and 4 can protect themselves against such tricks without kernel means.
  2 - Much harder to defeat, but with a good kernel debugger, it's possible to find anything.
  3 - A kernel debugger won't work here directly, unless you know the vector which launches the rootkit (for example, if it loads via BIOS code in your GPU, then things could get very tricky), however it's possible to detect virtualization in general via timing tricks - some instructions need to be virtualized, which means they'll run slower than in a non-virtualized OS by a few orders of magnitude. You can execute such code and do internal+external timing to detect if you're running virtualized. It's also possible to disable such features in BIOS, providing you can trust your BIOS to not be compromised.

tl;dr: Many methods to do what you want OP, everything is detectable of course, as no system is closed to a skilled enough reverse engineer. If you really want practical examples, see rootkit.com or just grab some real world samples and reverse them yourself.

code in: C++, C#, or VB.net appreciated. Anything else is fine, but it'll be a hassle.
This is usually low-level code, which means it's written in a combination of C and assembly in average. C++ could work, but why do you need the extra complexity for such low-level stuff?

erm, I meant >>14, damn typos.

>>12
I tried googling it. Could it be that Google hides information from us?

YBHT

>>14
right but it will (or should a least) trigger an antivirus program.

>>19
Antiviruses are programs themselves, they don't really operate outside of the box, nor can they anticipate every trick a program may use. For an antivirus to detect most of those tricks, it has to be very intrusive and hook a lot of kernel-mode and user-mode APIs. Passive antiviruses which only do static analysis or signature-based ones, are even more prone to failure as defeating unknown obfuscations/protectors is NP-complete. Try getting some obfuscated 0day malware samples and scanning them with some 20-30 antiviruses - I'll be surprised if the failure rate is not higher than 95% (failed to detect, or incorrectly detected as some generally suspicious threat). The problem is antiviruses base their analysis on some (reasonably fast) heuristics, and that will only catch known threats, but creating unknown threats that are not detected is not a hard problem. Another problem is that some of this rootkit-like behaviour is actually used by legitimate programs to perform some of their tasks, including antiviruses themselves, which means that they must err on the side of caution, lest they incorrectly flag a lot of innocent applications. Writing a perfect virus detector is no more simpler to solve than the halting problem(undecidable).